in reply to Re^4: SEGVs building Perl 5.10 on Solaris 10?
in thread SEGVs building Perl 5.10 on Solaris 10?

Indeed, as you say, doesn't really shed any light, however, rather than ...just after opening lib/strict.pm, we can see the fault occurs just after strict.pm has been successfully both read and closed - the last successful call is
. . . close(4) = 0
BTW, it might (if you've not already tried it), be worth using the -f switch to truss - I'm sure I'm telling my granny how to suck eggs - to follow any sub/spawned processes.

A user level that continues to overstate my experience :-))

Replies are listed 'Best First'.
Re^6: SEGVs building Perl 5.10 on Solaris 10?
by Llew_Llaw_Gyffes (Scribe) on Apr 24, 2009 at 14:13 UTC

    Oh, yes, you're right, it did successfully close strict.pm. Somehow I missed that line.

    Truss -f, unfortunately, does not add any additional information. (Except, I suppose, that the fact it doesn't add any information implies miniperl is dying before any additional processes have been spawned. "The dog did not bark, Watson.")

      I've just noticed
      LD_LIBRARY_PATH=/netstore/src/perl-5.10.0 ./miniperl -w -Ilib -MExpor +ter -e '<?>' || make minitest LD_LIBRARY_PATH=/netstore/src/perl-5.10.0 ./miniperl -Ilib configpm Segmentation Fault - core dumped make: *** [lib/Config.pod] Error 139
      Which means that miniperl has already been compiled and linked and it [miniperl] has successfully been used, the problem arises from building the config (seemingly by running the configpm script) ... one wonders if there's any mileage to compiling miniperl with DEBUG on - AFAIR, means defining -DDEBUG - and seeing if there's anything more useful generated, by way of debug output, by miniperl before it falls off it's perch...

      A user level that continues to overstate my experience :-))
        Funny you should say that, I was just pondering enabling debug and recompiling everything built so far in order to trace it in gdb.