Re: Double free problem using bytecode
Yoann Padioleau <[email protected]> Thu, 4 Nov 2010 09:17:25 -0700
| Newsgroups | gmane.comp.lang.ocaml.lib.gtk |
|---|---|
| Message-ID | <[email protected]> |
I have the same problem with pfff_visual ( https://github.com/facebook/pfff/wiki/Main ) on Linux in bytecode too. Native code works fine. master~/pfff $ ./pfff_visual -with_layer /tmp/layer_security.json facebook/tests/mini_www/ Using root = /data/users/pad/github/pfff/facebook/tests/mini_www/ "/data/users/pad/github/pfff/facebook/tests/mini_www/" 93 rectangles to draw Using Cairo version: 1.2.4 Size of model = 1 paint, with zoom = 1.000000, xtrans = 0.000000, ytrans = 0.000000 p:0.000000, 0.000000; q:1.600000, 1.000000 *** glibc detected *** /home/pad/pfff/pfff_visual: double free or corruption (!prev): 0x0000000000745510 *** ======= Backtrace: ========= /lib64/libc.so.6[0x3435e71834] /lib64/libc.so.6(cfree+0x8c)[0x3435e74e7c] /home/pad/pfff/pfff_visual[0x45416a] /home/pad/pfff/pfff_visual[0x448183] /home/pad/pfff/pfff_visual[0x4485fe] /lib64/libpthread.so.0[0x3436a062f7] /lib64/libc.so.6(clone+0x6d)[0x3435ed1e3d] ======= Memory map: ======== 00400000-00490000 r-xp 00000000 08:03 15114579 /data/users/pad/github/pfff/pfff_visual 0068f000-0069c000 rw-p 0008f000 08:03 15114579 /data/users/pad/github/pfff/pfff_visual 0069c000-00907000 rw-p 0069c000 00:00 0 [heap] 40000000-40001000 ---p 40000000 00:00 0 40001000-430d4000 rw-p 40001000 00:00 0 430d4000-430d5000 ---p 430d4000 00:00 0 430d5000-461a8000 rw-p 430d5000 00:00 0 3435600000-343561a000 r-xp 00000000 08:03 10027306 /lib64/ld-2.5.so 343581a000-343581b000 r--p 0001a000 08:03 10027306 /lib64/ld-2.5.so 343581b000-343581c000 rw-p 0001b000 08:03 10027306 /lib64/ld-2.5.so 3435a00000-3435a14000 r-xp 00000000 08:03 30576729 /usr/lib64/libz.so.1.2.3 3435a14000-3435c13000 ---p 00014000 08:03 30576729 /usr/lib64/libz.so.1.2.3 3435c13000-3435c14000 rw-p 00013000 08:03 30576729 /usr/lib64/libz.so.1.2.3 3435e00000-3435f4a000 r-xp 00000000 08:03 10027307 /lib64/libc-2.5.so 3435f4a000-343614a000 ---p 0014a000 08:03 10027307 /lib64/libc-2.5.so 343614a000-343614e000 r--p 0014a000 08:03 10027307 /lib64/libc-2.5.so 343614e000-343614f000 rw-p 0014e000 08:03 10027307 /lib64/libc-2.5.so 343614f000-3436154000 rw-p 343614f000 00:00 0 3436200000-3436202000 r-xp 00000000 08:03 10027308 /lib64/libdl-2.5.so 3436202000-3436402000 ---p 00002000 08:03 10027308 /lib64/libdl-2.5.so 3436402000-3436403000 r--p 00002000 08:03 10027308 /lib64/libdl-2.5.so 3436403000-3436404000 rw-p 00003000 08:03 10027308 /lib64/libdl-2.5.so 3436600000-3436682000 r-xp 00000000 08:03 10027313 /lib64/libm-2.5.so 3436682000-3436881000 ---p 00082000 08:03 10027313 /lib64/libm-2.5.so 3436881000-3436882000 r--p 00081000 08:03 10027313 /lib64/libm-2.5.so 3436882000-3436883000 rw-p 00082000 08:03 10027313 /lib64/libm-2.5.so 3436a00000-3436a15000 r-xp 00000000 08:03 10027312 /lib64/libpthread-2.5.so 3436a15000-3436c14000 ---p 00015000 08:03 10027312 /lib64/libpthread-2.5.so 3436c14000-3436c15000 r--p 00014000 08:03 10027312 /lib64/libpthread-2.5.so 3436c15000-3436c16000 rw-p 00015000 08:03 10027312 /lib64/libpthread-2.5.so 3436c16000-3436c1a000 rw-p 3436c16000 00:00 0 3436e00000-3436ef1000 r-xp 00000000 08:03 10027214 /lib64/libdb-4.3.so 3436ef1000-34370f0000 ---p 000f1000 08:03 10027214 /lib64/libdb-4.3.so 34370f0000-34370f5000 rw-p 000f0000 08:03 10027214 /lib64/libdb-4.3.so 3437200000-343720a000 r-xp 00000000 08:03 10027183 /lib64/libnss_files-2.5.so 343720a000-3437409000 ---p 0000a000 08:03 10027183 /lib64/libnss_files-2.5.so 3437409000-343740a000 r--p 00009000 08:03 10027183 /lib64/libnss_files-2.5.so 343740a000-343740b000 rw-p 0000a000 08:03 10027183 /lib64/libnss_files-2.5.so 3437600000-3437607000 r-xp 00000000 08:03 10027314 /lib64/librt-2.5.so 3437607000-3437807000 ---p 00007000 08:03 10027314 /lib64/librt-2.5.so 3437807000-3437808000 r--p 00007000 08:03 10027314 /lib64/librt-2.5.so 3437808000-3437809000 rw-p 000080aborted On Nov 4, 2010, at 4:30 AM, Hugo Herbelin wrote: > > Hi, > > We use lablgtk for the CoqIDE interface to Coq and we have "double > free" problems on Linux with the bytecode version of the interface [1]. > > The problem is solved by ensuring that any call to gtk from the > non-main thread are made using the sync/async functions. Is this then > a discipline that is recommended not only for Windows but also for > bytecode on Unix? > > Strangely, the problem is also solved by enforcing some dummy printing > on stderr from time to time. > > Using valgrind, we could somehow trace the "double free" problem (see > bottom of message). It shows that what is asked twice to be released > is the pointer to the block used as a stack by the bytecode runtime, > namely caml_stack_low: at some time an extension of the stack is done, > a new bigger stack is allocated and the old caml_stack_low pointer is > released. However, it looks like the updating of the caml_stack_low > using the address of new stack gets broken when using gtk in threads > since a second request for releasing the (old) value of the > caml_stack_low pointer happens later on (unfortunately, but that may > be also a hint, valgrind has no information on the call stack of the > second call to free). > > Does anyone has an idea of what happens and of why using sync/async > solves the problem? > > Hugo Herbelin and Stéphane Glondu > with the additional help of Vincent Gross > > [1] http://www.lix.polytechnique.fr/coq/bugs/show_bug.cgi?id=2062 > > ---------------------------------------------------------------------- > valgrind trace > > ==755== Command: bin/coqide.byte > ==755== > ==755== Thread 3: > ==755== Invalid free() / delete / delete[] > ==755== at 0x4C240FD: free (vg_replace_malloc.c:366) > ==755== Address 0x10c3dff0 is 0 bytes inside a block of size 8,192 free'd > ==755== at 0x4C240FD: free (vg_replace_malloc.c:366) > ==755== by 0x40AEF1: caml_stat_free (in /usr/local/bin/ocamlrun) > ==755== by 0x40AD1C: caml_realloc_stack (in /usr/local/bin/ocamlrun) > ==755== by 0x41B0BD: caml_interprete (in /usr/local/bin/ocamlrun) > ==755== by 0x41706C: caml_callbackN_exn (in /usr/local/bin/ocamlrun) > ==755== by 0x417164: caml_callback_exn (in /usr/local/bin/ocamlrun) > ==755== by 0x69570A8: caml_thread_start (in /usr/local/lib/ocaml/stublibs/dllthreads.so) > > _______________________________________________ > Lablgtk mailing list > [email protected] > http://yquem.inria.fr/cgi-bin/mailman/listinfo/lablgtk >