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

Applicable ulimits shouldn't be a problem, as I'm working as root at the moment. The SUNWscat pointer is a useful one, and I shall try it right away to see whether it sheds any light. Thanks. :)
  • Comment on Re^2: SEGVs building Perl 5.10 on Solaris 10?

Replies are listed 'Best First'.
Re^3: SEGVs building Perl 5.10 on Solaris 10?
by Bloodnok (Vicar) on Apr 24, 2009 at 13:30 UTC
    Presumably, you've already been down the truss(1M) road in an attempt to identify the root cause ...

    A user level that continues to overstate my experience :-))
[reply]
[d/l]
      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.
[reply]
[d/l]
        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]

In Section Seekers of Perl Wisdom