Delivered-To: garrigue at math.nagoya-u.ac.jp Delivered-To: lablgtk at yquem.inria.fr Subject: Re: [Lablgtk] Double free problem using bytecode Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: Yoann Padioleau In-Reply-To: <20101104113045.GA21006 at pirogue.inria.fr> Date: Thu, 4 Nov 2010 09:17:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3EAF9B1A-0B11-4E43-874A-6E13CC9CA583 at wanadoo.fr> References: <20101104113045.GA21006 at pirogue.inria.fr> To: Hugo Herbelin , Jacques Garrigue Cc: lablgtk at yquem.inria.fr, coqdev at inria.fr Status: U 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 =3D /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 =3D 1 paint, with zoom =3D 1.000000, xtrans =3D 0.000000, ytrans =3D 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 *** =3D=3D=3D=3D=3D=3D=3D Backtrace: =3D=3D=3D=3D=3D=3D=3D=3D=3D /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] =3D=3D=3D=3D=3D=3D=3D Memory map: =3D=3D=3D=3D=3D=3D=3D=3D 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=20 40001000-430d4000 rw-p 40001000 00:00 0=20 430d4000-430d5000 ---p 430d4000 00:00 0=20 430d5000-461a8000 rw-p 430d5000 00:00 0=20 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=20 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=20 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: >=20 > Hi, >=20 > 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]. >=20 > 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? >=20 > Strangely, the problem is also solved by enforcing some dummy printing > on stderr from time to time. >=20 > 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). >=20 > Does anyone has an idea of what happens and of why using sync/async > solves the problem? >=20 > Hugo Herbelin and St=E9phane Glondu > with the additional help of Vincent Gross >=20 > [1] http://www.lix.polytechnique.fr/coq/bugs/show_bug.cgi?id=3D2062 >=20 > ---------------------------------------------------------------------- > valgrind trace >=20 > =3D=3D755=3D=3D Command: bin/coqide.byte > =3D=3D755=3D=3D > =3D=3D755=3D=3D Thread 3: > =3D=3D755=3D=3D Invalid free() / delete / delete[] > =3D=3D755=3D=3D at 0x4C240FD: free (vg_replace_malloc.c:366) > =3D=3D755=3D=3D Address 0x10c3dff0 is 0 bytes inside a block of size = 8,192 free'd > =3D=3D755=3D=3D at 0x4C240FD: free (vg_replace_malloc.c:366) > =3D=3D755=3D=3D by 0x40AEF1: caml_stat_free (in = /usr/local/bin/ocamlrun) > =3D=3D755=3D=3D by 0x40AD1C: caml_realloc_stack (in = /usr/local/bin/ocamlrun) > =3D=3D755=3D=3D by 0x41B0BD: caml_interprete (in = /usr/local/bin/ocamlrun) > =3D=3D755=3D=3D by 0x41706C: caml_callbackN_exn (in = /usr/local/bin/ocamlrun) > =3D=3D755=3D=3D by 0x417164: caml_callback_exn (in = /usr/local/bin/ocamlrun) > =3D=3D755=3D=3D by 0x69570A8: caml_thread_start (in = /usr/local/lib/ocaml/stublibs/dllthreads.so) >=20 > _______________________________________________ > Lablgtk mailing list > Lablgtk@yquem.inria.fr > http://yquem.inria.fr/cgi-bin/mailman/listinfo/lablgtk >=20 _______________________________________________ Lablgtk mailing list Lablgtk@yquem.inria.fr http://yquem.inria.fr/cgi-bin/mailman/listinfo/lablgtk