| [reply] [Watch: Dir/Any] [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
...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] [Watch: Dir/Any] [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
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] [Watch: Dir/Any] [d/l] |