With COMPILE_DEBUG:
| % ./pike -m master.pike . . . | th(0) start_new_program(64, /home/mirar/Pike7.5-20030109-040008/src/module.c): threads_disabled:0, compilation_depth:0 | th(0) 0x83afec8 low_start_new_program() - pass=1: threads_disabled:0, compilation_depth:1 | th(0) 0x83afec8 end_first_pass(1): threads_disabled:0, compilation_depth:1 | th(0) 0x83b2160 end_first_pass(1): threads_disabled:0, compilation_depth:0
(init_modules ends here)
| th(0) (nil) compile() enter, placeholder=(nil) | th(0) 0x83afdf0 low_start_new_program() - pass=0: threads_disabled:0, compilation_depth:0 | th(0) 0x83afdf0 run_pass1() start: threads_disabled:0, compilation_depth:0
(yyparse is called here)
| Segmentation fault (core dumped)
Any way to debug/trace yyparse?
So it's yyparse itself that segfaults and you don't get any useful line number info in it?
/ Martin Stjernholm, Roxen IS
Previous text:
2003-01-09 12:28: Subject: --with-machine-code continued
With COMPILE_DEBUG:
| % ./pike -m master.pike . . . | th(0) start_new_program(64, /home/mirar/Pike7.5-20030109-040008/src/module.c): threads_disabled:0, compilation_depth:0 | th(0) 0x83afec8 low_start_new_program() - pass=1: threads_disabled:0, compilation_depth:1 | th(0) 0x83afec8 end_first_pass(1): threads_disabled:0, compilation_depth:1 | th(0) 0x83b2160 end_first_pass(1): threads_disabled:0, compilation_depth:0
(init_modules ends here)
| th(0) (nil) compile() enter, placeholder=(nil) | th(0) 0x83afdf0 low_start_new_program() - pass=0: threads_disabled:0, compilation_depth:0 | th(0) 0x83afdf0 run_pass1() start: threads_disabled:0, compilation_depth:0
(yyparse is called here)
| Segmentation fault (core dumped)
Any way to debug/trace yyparse?
/ Mirar
Yes, and GDB doesn't understand the stack when the segfault has occured.
Hm, interesting, with --with-dmalloc I get:
| (gdb) run -m master.pike | Starting program: /home/mirar/Pike7.5-20030109-040008/orchid/pike -m master.pike | [New Thread 16384 (LWP 32334)] | /home/mirar/Pike7.5-20030109-040008/src/callback.c:41: Fatal error: | Block alloc callback not initialized. | No stack - no backtrace. | | Program received signal SIGABRT, Aborted. | [Switching to Thread 16384 (LWP 32334)] | 0x2ab73031 in kill () from /lib/libc.so.6 | (gdb) bt | #0 0x2ab73031 in kill () from /lib/libc.so.6 | #1 0x2ab72c28 in raise () from /lib/libc.so.6 | #2 0x2ab7472b in abort () from /lib/libc.so.6 | #3 0x080e72a7 in debug_fatal (fmt=0x82d53c0 "Block alloc callback not initialized.\n") | at /home/mirar/Pike7.5-20030109-040008/src/error.c:404 | Cannot access memory at address 0x7fffffff
(--with-rtldebug --with-debug --with-cdebug --without-threads --with-compiler-trace --with-dmalloc, I'll reconfigure without dmalloc now...)
/ Mirar
Previous text:
2003-01-09 12:42: Subject: --with-machine-code continued
So it's yyparse itself that segfaults and you don't get any useful line number info in it?
/ Martin Stjernholm, Roxen IS
It's very sensitive. It stops crashing very easily. I think it stops crashing if I turn on --with-compiler-trace.
Is there any way of letting gdb or any other tool trace a C program, other then doing 's' a megazillion times?
/ Mirar
Previous text:
2003-01-09 12:53: Subject: --with-machine-code continued
Yes, and GDB doesn't understand the stack when the segfault has occured.
Hm, interesting, with --with-dmalloc I get:
| (gdb) run -m master.pike | Starting program: /home/mirar/Pike7.5-20030109-040008/orchid/pike -m master.pike | [New Thread 16384 (LWP 32334)] | /home/mirar/Pike7.5-20030109-040008/src/callback.c:41: Fatal error: | Block alloc callback not initialized. | No stack - no backtrace. | | Program received signal SIGABRT, Aborted. | [Switching to Thread 16384 (LWP 32334)] | 0x2ab73031 in kill () from /lib/libc.so.6 | (gdb) bt | #0 0x2ab73031 in kill () from /lib/libc.so.6 | #1 0x2ab72c28 in raise () from /lib/libc.so.6 | #2 0x2ab7472b in abort () from /lib/libc.so.6 | #3 0x080e72a7 in debug_fatal (fmt=0x82d53c0 "Block alloc callback not initialized.\n") | at /home/mirar/Pike7.5-20030109-040008/src/error.c:404 | Cannot access memory at address 0x7fffffff
(--with-rtldebug --with-debug --with-cdebug --without-threads --with-compiler-trace --with-dmalloc, I'll reconfigure without dmalloc now...)
/ Mirar
My gdb doesn't understand the addresses in the generated machine code (for natural reasons), but it manages to list the stack both above and below it. Maybe you can examine the pc and the stack yourself and see if you succeed better than gdb in determining the locations where it fails?
/ Martin Stjernholm, Roxen IS
Previous text:
2003-01-09 12:53: Subject: --with-machine-code continued
Yes, and GDB doesn't understand the stack when the segfault has occured.
Hm, interesting, with --with-dmalloc I get:
| (gdb) run -m master.pike | Starting program: /home/mirar/Pike7.5-20030109-040008/orchid/pike -m master.pike | [New Thread 16384 (LWP 32334)] | /home/mirar/Pike7.5-20030109-040008/src/callback.c:41: Fatal error: | Block alloc callback not initialized. | No stack - no backtrace. | | Program received signal SIGABRT, Aborted. | [Switching to Thread 16384 (LWP 32334)] | 0x2ab73031 in kill () from /lib/libc.so.6 | (gdb) bt | #0 0x2ab73031 in kill () from /lib/libc.so.6 | #1 0x2ab72c28 in raise () from /lib/libc.so.6 | #2 0x2ab7472b in abort () from /lib/libc.so.6 | #3 0x080e72a7 in debug_fatal (fmt=0x82d53c0 "Block alloc callback not initialized.\n") | at /home/mirar/Pike7.5-20030109-040008/src/error.c:404 | Cannot access memory at address 0x7fffffff
(--with-rtldebug --with-debug --with-cdebug --without-threads --with-compiler-trace --with-dmalloc, I'll reconfigure without dmalloc now...)
/ Mirar
I'm not very proficient in reading stacks. How do I do it?
/ Mirar
Previous text:
2003-01-09 13:33: Subject: --with-machine-code continued
My gdb doesn't understand the addresses in the generated machine code (for natural reasons), but it manages to list the stack both above and below it. Maybe you can examine the pc and the stack yourself and see if you succeed better than gdb in determining the locations where it fails?
/ Martin Stjernholm, Roxen IS
I don't know in detail, but I'd just try to interpret each word a bit down from the bogus frame as return address and see if it's plausible.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-01-09 13:50: Subject: --with-machine-code continued
I'm not very proficient in reading stacks. How do I do it?
/ Mirar
Or try another version of gdb. Mine calls itself "GNU gdb 2002-04-01-cvs" (it's 5.2-ish) and has, as I said, no problems with the stack frames in the generated machine code on my x86 Linux.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-01-09 13:54: Subject: --with-machine-code continued
I don't know in detail, but I'd just try to interpret each word a bit down from the bogus frame as return address and see if it's plausible.
/ Martin Stjernholm, Roxen IS
The problem seems to go away if I lowered the optimization levels (from make.conf).
Something in yyparse seems to go wrong with too much optimization - I'm not sure if the machine code is directly involved, it might very well be overoptimization of the code used to generate the machine code.
Or does it run generated machine code while it compiles?
If the problem goes away by lowering the optimization levels for yyparse.c, should I make it do so per default, locally for yyparse.c?
/ Mirar
Previous text:
2003-01-09 14:03: Subject: --with-machine-code continued
Or try another version of gdb. Mine calls itself "GNU gdb 2002-04-01-cvs" (it's 5.2-ish) and has, as I said, no problems with the stack frames in the generated machine code on my x86 Linux.
/ Martin Stjernholm, Roxen IS
Yes, it might very well run generated machine code while it compiles, e.g. when evaluating constant values.
Generally lowering the optimization is a bit too blunt in my opinion; narrowing it down to the specific breakage and perhaps reformulating some code somewhere is a more bearable kludge. If you don't want to dig any further in it, I think the blunt kludge is instead to prononounce gcc x.xx.x broken and avoid it or perhaps lowering the optimization when it's used.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-01-09 17:35: Subject: --with-machine-code continued
The problem seems to go away if I lowered the optimization levels (from make.conf).
Something in yyparse seems to go wrong with too much optimization - I'm not sure if the machine code is directly involved, it might very well be overoptimization of the code used to generate the machine code.
Or does it run generated machine code while it compiles?
If the problem goes away by lowering the optimization levels for yyparse.c, should I make it do so per default, locally for yyparse.c?
/ Mirar
Yes. It seems that the problem is around the CALL_MACHINE_CODE in interpret.c - I only need to compile that file without -fomit-frame-pointer, and the error is in CALL_MACHINE_CODE.
Is the calling convention changed in -fomit-frame-pointer? Is it possible to detect and support it?
If not, I'll add so that interpret.c will be compiled with -fno-omit-frame-pointer last, if -fomit-frame-pointer is present in the optimization flags.
/ Mirar
Previous text:
2003-01-09 18:23: Subject: --with-machine-code continued
Yes, it might very well run generated machine code while it compiles, e.g. when evaluating constant values.
Generally lowering the optimization is a bit too blunt in my opinion; narrowing it down to the specific breakage and perhaps reformulating some code somewhere is a more bearable kludge. If you don't want to dig any further in it, I think the blunt kludge is instead to prononounce gcc x.xx.x broken and avoid it or perhaps lowering the optimization when it's used.
/ Martin Stjernholm, Roxen IS
pike-devel@lists.lysator.liu.se