[Monetdb-developers] memory problems (black smoke) from the [HEAD]
We (Henning and I) are currently experiencing some strange problems with the HEAD of Pathfinder. It looks like there is a problem with memory management in Pathfinder. On our 64 bit SuSe9.3 system crashes every time we do a second query through the Mapi interface.
* start Mserver, run mil_start(); * then run through the MapiClient interface 2 times the query "1+1" Now the Mserver crashes and gdb gives:
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1107310944 (LWP 4579)] 0x00002aaaac67e3d2 in memcpy () from /lib64/tls/libc.so.6 (gdb) where #0 0x00002aaaac67e3d2 in memcpy () from /lib64/tls/libc.so.6 #1 0x00002aaab6546150 in ?? () #2 0x00002aaab4c31c02 in mem_realloc (pa=<value optimized out>, p=0x0, n=2048) at mem.c:133 #3 0x00002aaab4c31c4e in PFrealloc_ (n=<value optimized out>, mem=<value optimized out>, file=0x2aaab4d1212c "array.c", func=0x2aaab4d120fc "PFarray_at", line=128) at mem.c:165 #4 0x00002aaab4c3130b in PFarray_at (a=0x2aaab6546970, i=1) at array.c:128 #5 0x00002aaab4c32d28 in PFqname (ns={prefix = 0x0, uri = 0x0}, loc=0x0) at qname.c:188 #6 0x00002aaab4b98730 in PFty_xs_anyAttribute () at types.c:675 #7 0x00002aaab4b99f81 in PFfun_xquery_fo () at xquery_fo.c:122 #8 0x00002aaab4b797a0 in PFcompile_MonetDB (xquery=0xff83b9 "1+1\n", url=0xff83b9 "1+1\n", prologue=0x42002a08, query=0x42002960, epilogue=0x42002a18, options=<value optimized out>) at compile.c:730 #9 0x00002aaab4b76e22 in xquery_compile_exec (ctx=0x6227b8, url=0xff83b9 "1+1\n", is_url=0, prologue=0x42002a08, query=0x42002a10, epilogue=0x42002a18, nsurl=0x0) at pathfinder.mx:3586 #10 0x00002aaab4b78207 in xquery_prepare (ctx=0x6227b8, usec=18557579, query=0xff83b9 "1+1\n") at pathfinder.mx:4911 #11 0x00002aaab4b794ee in xquery_client_engine (fc=0x2aaab4fc1ad8) at pathfinder.mx:5054 #12 0x00002aaab4ebf882 in mapi_client_engine (FC=<value optimized out>) at mapi.mx:509 #13 0x00002aaaabfcd84f in start_thread () from /lib64/tls/libpthread.so.0 #14 0x00002aaaac6c6703 in clone () from /lib64/tls/libc.so.6 #15 0x0000000000000000 in ?? () #16 0x0000000000000000 in ?? () #17 0x0000000000000000 in ?? () #18 0x0000000000000000 in ?? () [ etc etc etc]
On my 32 bit SuSE 9.3 system it crashes already in the first query:
* start Mserver, run mil_start();
teehuis software/SCRIPTS> MapiClient -p 50123 -lx xquery>1+1 more>MAPI = monetdb@localhost:50123 QUERY = 1+1 ERROR = !tree matching: NULL pointer passed to PFnormalize_label ! !# halted in normalize.brg (PFnormalize_label), line 3649 xquery>
Anybody any idea what changed lately. I heard that JanR was planning some changes in the memory allocator,
JanF.
On Tue, Jan 30, 2007 at 03:13:14PM +0100, Jan Flokstra wrote:
We (Henning and I) are currently experiencing some strange problems with the HEAD of Pathfinder. It looks like there is a problem with memory management in Pathfinder. On our 64 bit SuSe9.3 system crashes every time we do a second query through the Mapi interface.
I don't know if this is the cause of your problem, but the implementation of PFrealloc() is completely broken (there's already a bug report on file).
In the gdb trace that you sent, PFrealloc() is called with a NULL pointer argument. Though the documentation in include/mem.h says `If mem is 0, this behaves like PFmalloc', the actual implementation will fail with the segmentation fault that you see. Most probably, this error sneaked in when the Boehm garbage collector was disabled in Pathfinder.
Since we have seen some problems with memory management in the recent past, Jan R already introduced the Boehm garbage collector back into Pathfinder. But it will only be enabled in the standalone compiler and if it was found during the ./configure run.
What remains a bit strange in your gdb trace is that PFrealloc() is called with a NULL pointer after all. If I look into the code, the functions in array.c shouldn't do that.
[...] 0x00002aaaac67e3d2 in memcpy () from /lib64/tls/libc.so.6 (gdb) where #0 0x00002aaaac67e3d2 in memcpy () from /lib64/tls/libc.so.6 #1 0x00002aaab6546150 in ?? () #2 0x00002aaab4c31c02 in mem_realloc (pa=<value optimized out>, p=0x0, n=2048) at mem.c:133 #3 0x00002aaab4c31c4e in PFrealloc_ (n=<value optimized out>, mem=<value optimized out>, file=0x2aaab4d1212c "array.c", func=0x2aaab4d120fc "PFarray_at", line=128) at mem.c:165 [...]
Wishes from Munich,
Jens
participants (2)
-
Jan Flokstra -
Jens Teubner