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

Yes. Truss tells me it's an out-of-bounds address fault, apparently just after opening lib/strict.pm: 
read(3, " # ! . / m i n i p e r l".., 4096)     = 4096
stat("lib/strict.pmc", 0xFFFFFD7FFFDFD710)      Err#2 ENOENT
stat("lib/strict.pm", 0xFFFFFD7FFFDFD670)       = 0
open("lib/strict.pm", O_RDONLY)                 = 4
ioctl(4, TCGETA, 0xFFFFFD7FFFDFD430)            Err#25 ENOTTY
lseek(4, 0, SEEK_CUR)                           = 0
brk(0x00757EC0)                                 = 0
brk(0x0075BEC0)                                 = 0
read(4, " p a c k a g e   s t r i".., 4096)     = 3716
brk(0x0075BEC0)                                 = 0
brk(0x0075FEC0)                                 = 0
brk(0x0075FEC0)                                 = 0
brk(0x00763EC0)                                 = 0
lseek(4, 878, SEEK_SET)                         = 878
lseek(4, 0, SEEK_CUR)                           = 878
close(4)                                        = 0
    Incurred fault #6, FLTBOUNDS  %pc = 0x004C2F24
      siginfo: SIGSEGV SEGV_MAPERR addr=0x004C2F24
    Received signal #11, SIGSEGV [default]
      siginfo: SIGSEGV SEGV_MAPERR addr=0x004C2F24

[download]
...but doesn't really shed any light on why I'm getting an address fault there. I was hoping someone else had tried this build or a similar combination, run into the same problem, and knew a simple configuration change to solve it.

Replies are listed 'Best First'.
Re^5: SEGVs building Perl 5.10 on Solaris 10?
by Bloodnok (Vicar) on Apr 24, 2009 at 13:50 UTC
    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

    [download]
    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 :-))
[reply]
[d/l]

      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.")

[reply]
        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

        [download]
        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 :-))
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom