Again, gdb/strace output would be good. That way there would be a way to see where it actually dies.
By the way, an unrelated suggestion - how about adding support for the 'backtrace()' system call on platforms where it's available? It can be used to, on crashes (or demand) craate a stack trace such as this:
Stack dump: { /lib/i686/libpthread.so.0 [0x4003710c] /lib/i686/libc.so.6 [0x401684c8] majesty(Read__17CYLinuxFileSystemiPvUl+0x1d) [0x8268bc1] majesty(Unserialize__11CYLibHeaderi+0x2b) [0x8200b8b] majesty(__11CYLibHeaderi+0x2e) [0x82017d6] majesty(AddLibrary__12CYLibManagerRC8CYString+0x14e) [0x820469e] majesty(AddStaticCAMs__Fv+0x6b) [0x830f0e7] majesty(main+0x5bf) [0x81dcbfb] /lib/i686/libc.so.6(__libc_start_main+0xa2) [0x401573e2] majesty(XMapRaised+0x31) [0x81368b1] }
It's very specific to Linux (afaik) but can prove very useful when trying to debug someone elses problem (i.e it's more information than you would have received otherwise).
/ David Hedbor
Previous text:
2003-02-12 22:31: Subject: Re: Weird problem with Image.SVG in Pike 7.4/7.5
I have just confirmed the suspicion - code compiled with gcc 2.95 and full optimization works fine. So, now to see what gets overoptimized with gcc 3.2 -O2
marek
/ Brevbäraren
On Wed, Feb 12, 2003 at 10:40:06PM +0100, David Hedbor @ Pike developers forum scribbled:
Again, gdb/strace output would be good. That way there would be a way to see where it actually dies.
Output from strace:
5506 [4000d134] read(12,"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\210!\0"..., 1024) = 1024 5506 [4000cf1f] fstat64(12, {st_dev=makedev(3, 7), st_ino=41979580,st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=240, st_size=122740, st_atime=2003/02/12-22:56:01, st_mtime=2003/02/03-01:25:35, st_ctime=2003/02/03-23:27:05}) = 0 5506 [4000d5bd] old_mmap(NULL, 121648, PROT_READ|PROT_EXEC, MAP_PRIVATE, 12, 0) = 0x4084b000 5506 [4000d644] mprotect(0x40865000, 15152, PROT_NONE) = 0 5506 [4000d5bd] old_mmap(0x40865000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 12, 0x1a000) = 0x40865000 5506 [4000d0ed] close(12) = 0 5506 [4000d601] munmap(0x405ee000, 60619) = 0 5506 [4016c3b1] gettimeofday({1045086961, 185815}, NULL) = 0 5506 [080c25ab] --- SIGINT (Interrupt) @ 0 (0) --- 5506 [4019d944] write(9, "\2", 1) = 1 5506 [4010c8a0] sigreturn() = ? (mask now [RTMIN])
SIGINT is where I press Ctrl-C - it gets caught somewhere and process doesn't exit. As you see, not much there...
And the output from stracing the "healthy" pike:
5591 [4000d0b4] open(0x40622be8, O_RDONLY) = 12 5591 [4000d134] read(12,"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\210!\0"..., 1024) = 1024 5591 [4000cf1f] fstat64(12, {st_dev=makedev(3, 7), st_ino=41979580,st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=240, st _size=122740, st_atime=2003/02/12-23:00:24, st_mtime=2003/02/03-01:25:35,st_ctime=2003/02/03-23:27:05}) = 0 5591 [4000d5bd] old_mmap(NULL, 121648, PROT_READ|PROT_EXEC, MAP_PRIVATE, 12, 0) = 0x40873000 5591 [4000d644] mprotect(0x4088d000, 15152, PROT_NONE) = 0 5591 [4000d5bd] old_mmap(0x4088d000, 16384, PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED, 12, 0x1a000) = 0x4088d000 5591 [4000d0ed] close(12) = 0 5591 [4000d601] munmap(0x40616000, 60619) = 0 5591 [4016d3b1] gettimeofday({1045087224, 28059}, NULL) = 0 5591 [401a76a4] mprotect(0x83b5558, 0, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 5591 [4016d3b1] gettimeofday({1045087224, 28822}, NULL) = 0 5591 [401a76a4] mprotect(0x83a51b0, 104, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 5591 [4016d3b1] gettimeofday({1045087224, 29417}, NULL) = 0 5591 [4016d3b1] gettimeofday({1045087224, 29535}, NULL) = 0 5591 [4016d3b1] gettimeofday({1045087224, 29594}, NULL) = 0
marek
Right, strace is generally not so useful. ltrace is often a bit better (since it enables libc call tracing too). gdb is the best naturally. Does anyone know of a call tracing app that uses ptrace to trace in-program system calls btw?
/ David Hedbor
Previous text:
2003-02-12 23:05: Subject: Re: Weird problem with Image.SVG in Pike 7.4/7.5
On Wed, Feb 12, 2003 at 10:40:06PM +0100, David Hedbor @ Pike developers forum scribbled:
Again, gdb/strace output would be good. That way there would be a way to see where it actually dies.
Output from strace:
5506 [4000d134] read(12,"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\210!\0"..., 1024) = 1024 5506 [4000cf1f] fstat64(12, {st_dev=makedev(3, 7), st_ino=41979580,st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=240, st_size=122740, st_atime=2003/02/12-22:56:01, st_mtime=2003/02/03-01:25:35, st_ctime=2003/02/03-23:27:05}) = 0 5506 [4000d5bd] old_mmap(NULL, 121648, PROT_READ|PROT_EXEC, MAP_PRIVATE, 12, 0) = 0x4084b000 5506 [4000d644] mprotect(0x40865000, 15152, PROT_NONE) = 0 5506 [4000d5bd] old_mmap(0x40865000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 12, 0x1a000) = 0x40865000 5506 [4000d0ed] close(12) = 0 5506 [4000d601] munmap(0x405ee000, 60619) = 0 5506 [4016c3b1] gettimeofday({1045086961, 185815}, NULL) = 0 5506 [080c25ab] --- SIGINT (Interrupt) @ 0 (0) --- 5506 [4019d944] write(9, "\2", 1) = 1 5506 [4010c8a0] sigreturn() = ? (mask now [RTMIN])
SIGINT is where I press Ctrl-C - it gets caught somewhere and process doesn't exit. As you see, not much there...
And the output from stracing the "healthy" pike:
5591 [4000d0b4] open(0x40622be8, O_RDONLY) = 12 5591 [4000d134] read(12,"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\210!\0"..., 1024) = 1024 5591 [4000cf1f] fstat64(12, {st_dev=makedev(3, 7), st_ino=41979580,st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=240, st _size=122740, st_atime=2003/02/12-23:00:24, st_mtime=2003/02/03-01:25:35,st_ctime=2003/02/03-23:27:05}) = 0 5591 [4000d5bd] old_mmap(NULL, 121648, PROT_READ|PROT_EXEC, MAP_PRIVATE, 12, 0) = 0x40873000 5591 [4000d644] mprotect(0x4088d000, 15152, PROT_NONE) = 0 5591 [4000d5bd] old_mmap(0x4088d000, 16384, PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED, 12, 0x1a000) = 0x4088d000 5591 [4000d0ed] close(12) = 0 5591 [4000d601] munmap(0x40616000, 60619) = 0 5591 [4016d3b1] gettimeofday({1045087224, 28059}, NULL) = 0 5591 [401a76a4] mprotect(0x83b5558, 0, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 5591 [4016d3b1] gettimeofday({1045087224, 28822}, NULL) = 0 5591 [401a76a4] mprotect(0x83a51b0, 104, PROT_READ|PROT_WRITE|PROT_EXEC) = -1 EINVAL (Invalid argument) 5591 [4016d3b1] gettimeofday({1045087224, 29417}, NULL) = 0 5591 [4016d3b1] gettimeofday({1045087224, 29535}, NULL) = 0 5591 [4016d3b1] gettimeofday({1045087224, 29594}, NULL) = 0
marek
/ Brevbäraren
truss.
/ Per Hedbor ()
Previous text:
2003-02-12 23:12: Subject: Re: Weird problem with Image.SVG in Pike 7.4/7.5
Right, strace is generally not so useful. ltrace is often a bit better (since it enables libc call tracing too). gdb is the best naturally. Does anyone know of a call tracing app that uses ptrace to trace in-program system calls btw?
/ David Hedbor
On Wed, Feb 12, 2003 at 11:15:07PM +0100, David Hedbor @ Pike developers forum scribbled:
Right, strace is generally not so useful. ltrace is often a bit better (since it enables libc call tracing too). gdb is the best
in this case ltrace returned exactly the same data as strace :)
marek
I've never seen or used that call, but it sounds a lot more like a glibc function than a system call.
/ Niels Möller ()
Previous text:
2003-02-12 22:36: Subject: Re: Weird problem with Image.SVG in Pike 7.4/7.5
Again, gdb/strace output would be good. That way there would be a way to see where it actually dies.
By the way, an unrelated suggestion - how about adding support for the 'backtrace()' system call on platforms where it's available? It can be used to, on crashes (or demand) craate a stack trace such as this:
Stack dump: { /lib/i686/libpthread.so.0 [0x4003710c] /lib/i686/libc.so.6 [0x401684c8] majesty(Read__17CYLinuxFileSystemiPvUl+0x1d) [0x8268bc1] majesty(Unserialize__11CYLibHeaderi+0x2b) [0x8200b8b] majesty(__11CYLibHeaderi+0x2e) [0x82017d6] majesty(AddLibrary__12CYLibManagerRC8CYString+0x14e) [0x820469e] majesty(AddStaticCAMs__Fv+0x6b) [0x830f0e7] majesty(main+0x5bf) [0x81dcbfb] /lib/i686/libc.so.6(__libc_start_main+0xa2) [0x401573e2] majesty(XMapRaised+0x31) [0x81368b1] }
It's very specific to Linux (afaik) but can prove very useful when trying to debug someone elses problem (i.e it's more information than you would have received otherwise).
/ David Hedbor
The include file is definitely a part of glibc (see /usr/include/execinfo.h).
/ David Hedbor
Previous text:
2003-02-13 09:36: Subject: Re: Weird problem with Image.SVG in Pike 7.4/7.5
I've never seen or used that call, but it sounds a lot more like a glibc function than a system call.
/ Niels Möller ()
pike-devel@lists.lysator.liu.se