Stefan Manegold wrote:
On Fri, Jul 24, 2009 at 10:42:33PM +0200, Stefan de Konink wrote:
On Fri, 24 Jul 2009, Franck Routier wrote:
Monetdb is segfaulting, probably while interpreting a query or planning it. I first thought it had to do with data, but after emptying the tables, the query still makes monetdb segfault.
Error in syslog says:
[ 1230.812708] mserver5[5369]: segfault at 7fab4c2b5ff8 ip 00007fab4f894285 sp 00007fab4c2b6000 error 6 in lib_sql.so.2.30.2[7fab4f7e3000+116000]
Following is the faulty ddl / query. Is there anything I can do to help debug this ? For the dev guys that want to debug this; I'm giving it a shot aswel:
(gdb) bt #0 0x00007fa1097718ec in prop_destroy (p=0x0) at ../../../src/server/rel_prop.mx:54 #1 0x00007fa10977190a in prop_destroy (p=0x39165f8) at ../../../src/server/rel_prop.mx:56 #2 0x00007fa10977190a in prop_destroy (p=0x3916658) at ../../../src/server/rel_prop.mx:56 #3 0x00007fa10977190a in prop_destroy (p=0x3916688) at ../../../src/server/rel_prop.mx:56 #4 0x00007fa10977190a in prop_destroy (p=0x3916748) at ../../../src/server/rel_prop.mx:56 #5 0x00007fa10977190a in prop_destroy (p=0x3916778) at ../../../src/server/rel_prop.mx:56 #6 0x00007fa10977190a in prop_destroy (p=0x39167d8) at ../../../src/server/rel_prop.mx:56 #7 0x00007fa10977190a in prop_destroy (p=0x3916808) at ../../../src/server/rel_prop.mx:56 #8 0x00007fa10977190a in prop_destroy (p=0x3916898) at ../../../src/server/rel_prop.mx:56 #9 0x00007fa10977190a in prop_destroy (p=0x39168c8) at ../../../src/server/rel_prop.mx:56 #10 0x00007fa10977190a in prop_destroy (p=0x3916928) at ../../../src/server/rel_prop.mx:56 #11 0x00007fa10977190a in prop_destroy (p=0x3916958)
...goes on and on.
(gdb) list 49 #include "rel_semantic.h" 50 #include "rel_prop.h" 51 52 void 53 prop_destroy( prop *p ) 54 { 55 if (p->p) 56 prop_destroy(p->p); 57 _DELETE(p); 58 }
just a guess:
might be a stack overflow due to too deep recursion.
I can easily reproduce this on the up-to-date Stable branch (Fedora 10, 64 bits). This is indeed a case of too deep recursion: after sitting on the Enter key for a long time, the stack trace was up to 52000 levels and it was still going strong. All those levels were the recursive call Stefan deK indicated, but the arguments were different (at least in the sample I looked at), so it's not a simple loop in the linked list. -- Sjoerd Mullender