From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id CB1C4BC57 for ; Wed, 1 Dec 2010 00:08:34 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsDAJ8S9UzRVda2dGdsb2JhbACjBQgVAQwJDAcNAgUfqWKLfAEFjiYBBIVHimY X-IronPort-AV: E=Sophos;i="4.59,282,1288566000"; d="scan'208";a="81010892" Received: from mail-iw0-f182.google.com ([209.85.214.182]) by mail4-smtp-sop.national.inria.fr with ESMTP; 01 Dec 2010 00:08:33 +0100 Received: by iwn39 with SMTP id 39so8007251iwn.27 for ; Tue, 30 Nov 2010 15:08:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type; bh=AZnMyxg7BgPkBXLQ3A+hxZx2v4dPo4Oativc5WXoVC8=; b=DzlIjBo+tnB63YeV6y6Rg+pvXVMFOM6wNo/3CHsVkVDu8STFpB2Bn91bTvLuSGW6jx g4rhydoULCVxu2wXXBJ3+yZNRjd7zXeu/Od4ZQ6VIQmTrQjhHQQ2d3ZAyZrLyEGASL9u lXVqHRFccXiX344N1EzgY6zsem5R+/1MncxIM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=ZmjFKxF4MaCMnoARVQQuEin1n1SK4rM4dk+9nG0SmzgkKH6mpdJ1k1RlwAnKq9xxhk QnIDZW/e5UACwCQOTq5LRLcEK8w8Nc+nxs24Pi8/VXKOwaiwavT1UkLHT7l6Xir1HuVi C0Wgew/rbH+Jvv8d+5aY7RqTnuCngMPhr2T/c= Received: by 10.231.17.11 with SMTP id q11mr7976476iba.102.1291158512973; Tue, 30 Nov 2010 15:08:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.176.134 with HTTP; Tue, 30 Nov 2010 15:08:12 -0800 (PST) From: Philippe Veber Date: Wed, 1 Dec 2010 00:08:12 +0100 Message-ID: Subject: Tips to find the cause of a seg fault To: caml users Content-Type: multipart/alternative; boundary=00032557497e83c72d04964d4498 X-Spam: no; 0.00; lablgl:01 ocamlsdl:01 segfaults:01 gentoo:01 bytecode:01 marshaling:01 gdb:01 ocamlsdl:01 usr:01 lib:01 usr:01 lib:01 unhandled:01 bug:01 erroneously:01 --00032557497e83c72d04964d4498 Content-Type: text/plain; charset=ISO-8859-1 Short story (details below): I'm currently writing a program relying on react, lablgl and ocamlsdl. This program segfaults on my laptop under two linux distributions (ubuntu and gentoo) but doesn't on a PC under ubuntu. The seg fault occurs with both bytecode and native executables. I don't do any marshaling nor use any typing magic; stack overflow is not likely. I humbly ask this list about means to improve valgrind or gdb outputs, which don't report informative function names, or more generally, any tip that could help me to locate the origin of the problem. More details ============ The seg fault occurs when using the mouse wheel in the application, and only if it is rolled fast enough. By trial and error, I could track the problem up to a function of mine handling mouse events: when a click occurs, the sdl record describing the mouse event is passed to a callback function which looks like this: let picking_handler send = function | { mbe_button = BUTTON_WHEELDOWN ; mbe_state = RELEASED } -> send `zoom_out | { mbe_button = BUTTON_WHEELUP ; mbe_state = RELEASED } -> send `zoom_in | { mbe_button = BUTTON_LEFT ; mbe_state = RELEASED } -> assert false | _ -> () The seg fault occurs during the call to this function with the button event retrieved by ocamlsdl. What's *really* weird is that if I comment the third case of the pattern matching, the seg fault does not occur. This is strange since with the "assert false" expression, I make sure this case is useless (i don't press the left button). Also, in the various tests I made, I obtained different errors, like segmentation fault in caml_absf_mask or invalid instruction error. Of course I am not asking a solution to my problem, but maybe this may remind you of something. That is, any suggestion (other than "resign !" ;o)) will be greatly appreciated ! Philippe. PS Below, the output of valgrind ~/hum 23:10:20 $ valgrind ./hum.native ==11306== Memcheck, a memory error detector ==11306== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==11306== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info ==11306== Command: ./hum.native ==11306== ==11306== Conditional jump or move depends on uninitialised value(s) ==11306== at 0x7ABC820: ??? (in /usr/lib/nvidia-current/libnvidia-glcore.so.260.19.06) ==11306== by 0x85AED3F: ??? ==11306== by 0x85AED3F: ??? ==11306== by 0x7FEFFFF1F: ??? ==11306== by 0x7FEFFFFDF: ??? ==11306== by 0x7FEFFFFE7: ??? ==11306== by 0xF2C04F7: ??? (in /dev/zero) ==11306== by 0xF285FFF: ??? (in /usr/lib/libXfixes.so.3.1.0) ==11306== by 0x4002: ??? ==11306== by 0x1058619F: ??? ==11306== ==11306== Conditional jump or move depends on uninitialised value(s) ==11306== at 0x7ABC829: ??? (in /usr/lib/nvidia-current/libnvidia-glcore.so.260.19.06) ==11306== by 0x85AED3F: ??? ==11306== by 0x85AED3F: ??? ==11306== by 0x7FEFFFF1F: ??? ==11306== by 0x7FEFFFFDF: ??? ==11306== by 0x7FEFFFFE7: ??? ==11306== by 0xF2C04F7: ??? (in /dev/zero) ==11306== by 0xF285FFF: ??? (in /usr/lib/libXfixes.so.3.1.0) ==11306== by 0x4002: ??? ==11306== by 0x1058619F: ??? ==11306== ==11306== Use of uninitialised value of size 8 ==11306== at 0x7ABC836: ??? (in /usr/lib/nvidia-current/libnvidia-glcore.so.260.19.06) ==11306== by 0x85AED3F: ??? ==11306== by 0x85AED3F: ??? ==11306== by 0x7FEFFFF1F: ??? ==11306== by 0x7FEFFFFDF: ??? ==11306== by 0x7FEFFFFE7: ??? ==11306== by 0xF2C04F7: ??? (in /dev/zero) ==11306== by 0xF285FFF: ??? (in /usr/lib/libXfixes.so.3.1.0) ==11306== by 0x4002: ??? ==11306== by 0x1058619F: ??? ==11306== ==11306== Conditional jump or move depends on uninitialised value(s) ==11306== at 0x5B3D5E7: ??? (in /usr/lib/libSDL-1.2.so.0.11.3) ==11306== by 0x5B3DEAE: ??? (in /usr/lib/libSDL-1.2.so.0.11.3) ==11306== by 0x5B3E8CA: ??? (in /usr/lib/libSDL-1.2.so.0.11.3) ==11306== by 0x5B12F9F: SDL_PumpEvents (in /usr/lib/libSDL-1.2.so.0.11.3) ==11306== by 0x5B13368: SDL_WaitEvent (in /usr/lib/libSDL-1.2.so.0.11.3) ==11306== by 0x47ED83: mlsdlevent_wait_event (in /home/pveber/hum/_build/src/hum.native) ==11306== by 0x498DC3: ??? (in /home/pveber/hum/_build/src/hum.native) ==11306== by 0xC576ABF: ??? ==11306== by 0xC576B77: ??? ==11306== by 0xC55FCB7: ??? ==11306== by 0x4215D5: camlHum__entry (in /home/pveber/hum/_build/src/hum.native) ==11306== by 0xC5767A7: ??? ==11306== ==11306== Conditional jump or move depends on uninitialised value(s) ==11306== at 0x5B3D616: ??? (in /usr/lib/libSDL-1.2.so.0.11.3) ==11306== by 0x5B3DEAE: ??? (in /usr/lib/libSDL-1.2.so.0.11.3) ==11306== by 0x5B3E8CA: ??? (in /usr/lib/libSDL-1.2.so.0.11.3) ==11306== by 0x5B12F9F: SDL_PumpEvents (in /usr/lib/libSDL-1.2.so.0.11.3) ==11306== by 0x5B13368: SDL_WaitEvent (in /usr/lib/libSDL-1.2.so.0.11.3) ==11306== by 0x47ED83: mlsdlevent_wait_event (in /home/pveber/hum/_build/src/hum.native) ==11306== by 0x498DC3: ??? (in /home/pveber/hum/_build/src/hum.native) ==11306== by 0xC576ABF: ??? ==11306== by 0xC576B77: ??? ==11306== by 0xC55FCB7: ??? ==11306== by 0x4215D5: camlHum__entry (in /home/pveber/hum/_build/src/hum.native) ==11306== by 0xC5767A7: ??? ==11306== ==11306== Conditional jump or move depends on uninitialised value(s) ==11306== at 0x7695580: ??? (in /usr/lib/nvidia-current/libnvidia-glcore.so.260.19.06) ==11306== by 0x1000000000000: ??? ==11306== vex amd64->IR: unhandled instruction bytes: 0xFF 0xD8 0xC 0xF9 0xFF 0xD8 ==11306== valgrind: Unrecognised instruction at address 0x4992cb. ==11306== Your program just tried to execute an instruction that Valgrind ==11306== did not recognise. There are two possible reasons for this. ==11306== 1. Your program has a bug and erroneously jumped to a non-code ==11306== location. If you are running Memcheck and you just saw a ==11306== warning about a bad jump, it's probably your program's fault. ==11306== 2. The instruction is legitimate but Valgrind doesn't handle it, ==11306== i.e. it's Valgrind's fault. If you think this is the case or ==11306== you are not sure, please let us know and we'll try to fix it. ==11306== Either way, Valgrind will now raise a SIGILL signal which will ==11306== probably kill your program. ==11306== ==11306== Process terminating with default action of signal 4 (SIGILL) ==11306== Illegal opcode at address 0x4992CB ==11306== at 0x4992CB: ??? (in /home/pveber/hum/_build/src/hum.native) ==11306== by 0x422388: camlGui__trace_504 (in /home/pveber/hum/_build/src/hum.native) ==11306== by 0x1547AAB7: ??? ==11306== by 0xC54A70F: ??? ==11306== by 0x6B2857: ??? (in /home/pveber/hum/_build/src/hum.native) ==11306== by 0x42254E: camlGui__click_508 (in /home/pveber/hum/_build/src/hum.native) ==11306== by 0x7FF00036F: ??? ==11306== by 0x422504: camlGui__click_508 (in /home/pveber/hum/_build/src/hum.native) ==11306== by 0xC54897F: ??? ==11306== by 0x104: ??? ==11306== by 0x2: ??? ==11306== by 0x15487DF7: ??? ==11306== ==11306== HEAP SUMMARY: ==11306== in use at exit: 142,919,371 bytes in 77,584 blocks ==11306== total heap usage: 183,886 allocs, 106,302 frees, 294,404,168 bytes allocated ==11306== ==11306== LEAK SUMMARY: ==11306== definitely lost: 38 bytes in 3 blocks ==11306== indirectly lost: 176 bytes in 4 blocks ==11306== possibly lost: 66,443,601 bytes in 292 blocks ==11306== still reachable: 76,475,556 bytes in 77,285 blocks ==11306== suppressed: 0 bytes in 0 blocks ==11306== Rerun with --leak-check=full to see details of leaked memory ==11306== ==11306== For counts of detected and suppressed errors, rerun with: -v ==11306== Use --track-origins=yes to see where uninitialised values come from ==11306== ERROR SUMMARY: 1170520 errors from 7 contexts (suppressed: 7 from 7) Instruction non permise --00032557497e83c72d04964d4498 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Short story (details be= low): I'm currently writing a program relying on react, lablgl and ocam= lsdl. This program segfaults on my laptop under two linux distributions (ub= untu and gentoo) but doesn't on a PC under ubuntu. The seg fault occurs= with both bytecode and native executables. I don't do any marshaling n= or use any typing magic; stack overflow is not likely. I humbly ask this li= st about means to improve valgrind or gdb outputs, which don't report i= nformative function names, or more generally, any tip that could help me to= locate the origin of the problem.

More details
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The seg fault occurs when using the mouse wheel in the application, and= only if it is rolled fast enough. By trial and error, I could track the pr= oblem up to a function of mine handling mouse events: when a click occurs, = the sdl record describing the mouse event is passed to a callback function = which looks like this:

let picking_handler send =3D function
=A0 | { mbe_button =3D BUTTON= _WHEELDOWN ; mbe_state =3D RELEASED } ->
=A0=A0=A0=A0=A0 send `zoom_= out
=A0 | { mbe_button =3D BUTTON_WHEELUP ; mbe_state =3D RELEASED } -&g= t;
=A0=A0=A0=A0=A0 send `zoom_in
=A0 | { mbe_button =3D BUTTON_LEFT ; mbe_state =3D RELEASED } ->
=A0= =A0=A0 assert false
=A0 | _ -> ()

The seg fault occurs during = the call to this function with the button event retrieved by ocamlsdl. What= 's *really* weird is that if I comment the third case of the pattern ma= tching, the seg fault does not occur. This is strange since with the "= assert false" expression, I make sure this case is useless (i don'= t press the left button). Also, in the various tests I made, I obtained dif= ferent errors, like segmentation fault in caml_absf_mask or invalid instruc= tion error.

Of course I am not asking a solution to my problem, but maybe this may = remind you of something. That is, any suggestion (other than "resign != " ;o)) will be greatly appreciated !

Philippe.

PS Below,= the output of valgrind

~/hum 23:10:20 $ valgrind ./hum.native
=3D=3D11306=3D=3D Memcheck, = a memory error detector
=3D=3D11306=3D=3D Copyright (C) 2002-2010, and G= NU GPL'd, by Julian Seward et al.
=3D=3D11306=3D=3D Using Valgrind-3= .6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
=3D=3D11306=3D=3D Command: ./hum.native
=3D=3D11306=3D=3D
=3D=3D1130= 6=3D=3D Conditional jump or move depends on uninitialised value(s)
=3D= =3D11306=3D=3D=A0=A0=A0 at 0x7ABC820: ??? (in /usr/lib/nvidia-current/libnv= idia-glcore.so.260.19.06)
=3D=3D11306=3D=3D=A0=A0=A0 by 0x85AED3F: ??? =3D=3D11306=3D=3D=A0=A0=A0 by 0x85AED3F: ???
=3D=3D11306=3D=3D=A0=A0=A0 = by 0x7FEFFFF1F: ???
=3D=3D11306=3D=3D=A0=A0=A0 by 0x7FEFFFFDF: ???
= =3D=3D11306=3D=3D=A0=A0=A0 by 0x7FEFFFFE7: ???
=3D=3D11306=3D=3D=A0=A0= =A0 by 0xF2C04F7: ??? (in /dev/zero)
=3D=3D11306=3D=3D=A0=A0=A0 by 0xF28= 5FFF: ??? (in /usr/lib/libXfixes.so.3.1.0)
=3D=3D11306=3D=3D=A0=A0=A0 by 0x4002: ???
=3D=3D11306=3D=3D=A0=A0=A0 by = 0x1058619F: ???
=3D=3D11306=3D=3D
=3D=3D11306=3D=3D Conditional jump= or move depends on uninitialised value(s)
=3D=3D11306=3D=3D=A0=A0=A0 at= 0x7ABC829: ??? (in /usr/lib/nvidia-current/libnvidia-glcore.so.260.19.06)<= br> =3D=3D11306=3D=3D=A0=A0=A0 by 0x85AED3F: ???
=3D=3D11306=3D=3D=A0=A0=A0 = by 0x85AED3F: ???
=3D=3D11306=3D=3D=A0=A0=A0 by 0x7FEFFFF1F: ???
=3D= =3D11306=3D=3D=A0=A0=A0 by 0x7FEFFFFDF: ???
=3D=3D11306=3D=3D=A0=A0=A0 b= y 0x7FEFFFFE7: ???
=3D=3D11306=3D=3D=A0=A0=A0 by 0xF2C04F7: ??? (in /dev= /zero)
=3D=3D11306=3D=3D=A0=A0=A0 by 0xF285FFF: ??? (in /usr/lib/libXfixes.so.3.1.= 0)
=3D=3D11306=3D=3D=A0=A0=A0 by 0x4002: ???
=3D=3D11306=3D=3D=A0=A0= =A0 by 0x1058619F: ???
=3D=3D11306=3D=3D
=3D=3D11306=3D=3D Use of un= initialised value of size 8
=3D=3D11306=3D=3D=A0=A0=A0 at 0x7ABC836: ???= (in /usr/lib/nvidia-current/libnvidia-glcore.so.260.19.06)
=3D=3D11306=3D=3D=A0=A0=A0 by 0x85AED3F: ???
=3D=3D11306=3D=3D=A0=A0=A0 = by 0x85AED3F: ???
=3D=3D11306=3D=3D=A0=A0=A0 by 0x7FEFFFF1F: ???
=3D= =3D11306=3D=3D=A0=A0=A0 by 0x7FEFFFFDF: ???
=3D=3D11306=3D=3D=A0=A0=A0 b= y 0x7FEFFFFE7: ???
=3D=3D11306=3D=3D=A0=A0=A0 by 0xF2C04F7: ??? (in /dev= /zero)
=3D=3D11306=3D=3D=A0=A0=A0 by 0xF285FFF: ??? (in /usr/lib/libXfixes.so.3.1.= 0)
=3D=3D11306=3D=3D=A0=A0=A0 by 0x4002: ???
=3D=3D11306=3D=3D=A0=A0= =A0 by 0x1058619F: ???
=3D=3D11306=3D=3D
=3D=3D11306=3D=3D Condition= al jump or move depends on uninitialised value(s)
=3D=3D11306=3D=3D=A0= =A0=A0 at 0x5B3D5E7: ??? (in /usr/lib/libSDL-1.2.so.0.11.3)
=3D=3D11306=3D=3D=A0=A0=A0 by 0x5B3DEAE: ??? (in /usr/lib/libSDL-1.2.so.0.1= 1.3)
=3D=3D11306=3D=3D=A0=A0=A0 by 0x5B3E8CA: ??? (in /usr/lib/libSDL-1.= 2.so.0.11.3)
=3D=3D11306=3D=3D=A0=A0=A0 by 0x5B12F9F: SDL_PumpEvents (in= /usr/lib/libSDL-1.2.so.0.11.3)
=3D=3D11306=3D=3D=A0=A0=A0 by 0x5B13368:= SDL_WaitEvent (in /usr/lib/libSDL-1.2.so.0.11.3)
=3D=3D11306=3D=3D=A0=A0=A0 by 0x47ED83: mlsdlevent_wait_event (in /home/pve= ber/hum/_build/src/hum.native)
=3D=3D11306=3D=3D=A0=A0=A0 by 0x498DC3: ?= ?? (in /home/pveber/hum/_build/src/hum.native)
=3D=3D11306=3D=3D=A0=A0= =A0 by 0xC576ABF: ???
=3D=3D11306=3D=3D=A0=A0=A0 by 0xC576B77: ???
=3D=3D11306=3D=3D=A0=A0=A0 by 0xC55FCB7: ???
=3D=3D11306=3D=3D=A0=A0=A0 = by 0x4215D5: camlHum__entry (in /home/pveber/hum/_build/src/hum.native)
= =3D=3D11306=3D=3D=A0=A0=A0 by 0xC5767A7: ???
=3D=3D11306=3D=3D
=3D= =3D11306=3D=3D Conditional jump or move depends on uninitialised value(s) =3D=3D11306=3D=3D=A0=A0=A0 at 0x5B3D616: ??? (in /usr/lib/libSDL-1.2.so.0.1= 1.3)
=3D=3D11306=3D=3D=A0=A0=A0 by 0x5B3DEAE: ??? (in /usr/lib/libSDL-1.= 2.so.0.11.3)
=3D=3D11306=3D=3D=A0=A0=A0 by 0x5B3E8CA: ??? (in /usr/lib/l= ibSDL-1.2.so.0.11.3)
=3D=3D11306=3D=3D=A0=A0=A0 by 0x5B12F9F: SDL_PumpEv= ents (in /usr/lib/libSDL-1.2.so.0.11.3)
=3D=3D11306=3D=3D=A0=A0=A0 by 0x5B13368: SDL_WaitEvent (in /usr/lib/libSDL-= 1.2.so.0.11.3)
=3D=3D11306=3D=3D=A0=A0=A0 by 0x47ED83: mlsdlevent_wait_e= vent (in /home/pveber/hum/_build/src/hum.native)
=3D=3D11306=3D=3D=A0=A0= =A0 by 0x498DC3: ??? (in /home/pveber/hum/_build/src/hum.native)
=3D=3D11306=3D=3D=A0=A0=A0 by 0xC576ABF: ???
=3D=3D11306=3D=3D=A0=A0=A0 = by 0xC576B77: ???
=3D=3D11306=3D=3D=A0=A0=A0 by 0xC55FCB7: ???
=3D=3D= 11306=3D=3D=A0=A0=A0 by 0x4215D5: camlHum__entry (in /home/pveber/hum/_buil= d/src/hum.native)
=3D=3D11306=3D=3D=A0=A0=A0 by 0xC5767A7: ???
=3D=3D11306=3D=3D
=3D=3D11306=3D=3D Conditional jump or move depends on= uninitialised value(s)
=3D=3D11306=3D=3D=A0=A0=A0 at 0x7695580: ??? (in= /usr/lib/nvidia-current/libnvidia-glcore.so.260.19.06)
=3D=3D11306=3D= =3D=A0=A0=A0 by 0x1000000000000: ???
=3D=3D11306=3D=3D
vex amd64->IR: unhandled instruction bytes: 0xFF 0xD8 0xC 0xF9 0xFF 0xD8=
=3D=3D11306=3D=3D valgrind: Unrecognised instruction at address 0x4992c= b.
=3D=3D11306=3D=3D Your program just tried to execute an instruction t= hat Valgrind
=3D=3D11306=3D=3D did not recognise.=A0 There are two possible reasons for = this.
=3D=3D11306=3D=3D 1. Your program has a bug and erroneously jumped= to a non-code
=3D=3D11306=3D=3D=A0=A0=A0 location.=A0 If you are runnin= g Memcheck and you just saw a
=3D=3D11306=3D=3D=A0=A0=A0 warning about a bad jump, it's probably your= program's fault.
=3D=3D11306=3D=3D 2. The instruction is legitimate= but Valgrind doesn't handle it,
=3D=3D11306=3D=3D=A0=A0=A0 i.e. it&= #39;s Valgrind's fault.=A0 If you think this is the case or
=3D=3D11306=3D=3D=A0=A0=A0 you are not sure, please let us know and we'= ll try to fix it.
=3D=3D11306=3D=3D Either way, Valgrind will now raise = a SIGILL signal which will
=3D=3D11306=3D=3D probably kill your program.=
=3D=3D11306=3D=3D
=3D=3D11306=3D=3D Process terminating with defaul= t action of signal 4 (SIGILL)
=3D=3D11306=3D=3D=A0 Illegal opcode at address 0x4992CB
=3D=3D11306=3D= =3D=A0=A0=A0 at 0x4992CB: ??? (in /home/pveber/hum/_build/src/hum.native)=3D=3D11306=3D=3D=A0=A0=A0 by 0x422388: camlGui__trace_504 (in /home/pveb= er/hum/_build/src/hum.native)
=3D=3D11306=3D=3D=A0=A0=A0 by 0x1547AAB7: = ???
=3D=3D11306=3D=3D=A0=A0=A0 by 0xC54A70F: ???
=3D=3D11306=3D=3D=A0=A0=A0 = by 0x6B2857: ??? (in /home/pveber/hum/_build/src/hum.native)
=3D=3D11306= =3D=3D=A0=A0=A0 by 0x42254E: camlGui__click_508 (in /home/pveber/hum/_build= /src/hum.native)
=3D=3D11306=3D=3D=A0=A0=A0 by 0x7FF00036F: ???
=3D=3D11306=3D=3D=A0=A0=A0 by 0x422504: camlGui__click_508 (in /home/pveber= /hum/_build/src/hum.native)
=3D=3D11306=3D=3D=A0=A0=A0 by 0xC54897F: ???=
=3D=3D11306=3D=3D=A0=A0=A0 by 0x104: ???
=3D=3D11306=3D=3D=A0=A0=A0 = by 0x2: ???
=3D=3D11306=3D=3D=A0=A0=A0 by 0x15487DF7: ???
=3D=3D11306= =3D=3D
=3D=3D11306=3D=3D HEAP SUMMARY:
=3D=3D11306=3D=3D=A0=A0=A0=A0 in use at = exit: 142,919,371 bytes in 77,584 blocks
=3D=3D11306=3D=3D=A0=A0 total h= eap usage: 183,886 allocs, 106,302 frees, 294,404,168 bytes allocated
= =3D=3D11306=3D=3D
=3D=3D11306=3D=3D LEAK SUMMARY:
=3D=3D11306=3D=3D=A0=A0=A0 definitely lost: 38 bytes in 3 blocks
=3D=3D1= 1306=3D=3D=A0=A0=A0 indirectly lost: 176 bytes in 4 blocks
=3D=3D11306= =3D=3D=A0=A0=A0=A0=A0 possibly lost: 66,443,601 bytes in 292 blocks
=3D= =3D11306=3D=3D=A0=A0=A0 still reachable: 76,475,556 bytes in 77,285 blocks<= br> =3D=3D11306=3D=3D=A0=A0=A0=A0=A0=A0=A0=A0 suppressed: 0 bytes in 0 blocks=3D=3D11306=3D=3D Rerun with --leak-check=3Dfull to see details of leaked= memory
=3D=3D11306=3D=3D
=3D=3D11306=3D=3D For counts of detected a= nd suppressed errors, rerun with: -v
=3D=3D11306=3D=3D Use --track-origi= ns=3Dyes to see where uninitialised values come from
=3D=3D11306=3D=3D ERROR SUMMARY: 1170520 errors from 7 contexts (suppressed= : 7 from 7)
Instruction non permise


--00032557497e83c72d04964d4498--