Re: [Valgrind-users] Does valgrind work with Boehm garbage collector?
The execution recipe works for me on Fedora 28 using valgrind-3.14.0-7.fc28.x86_64. Also, the default on Mac is to use addresses greater than (1ul<<32). Because the program works when _not_ run under valgrind, then the conclusion is that valgrind-3.14.0-7 has a bug where it stores an address in 32 bits. To find the bug in valgrind: invoke a debug version of valgrind-3.14 under lldb on Mac, and then invoke main.l.exe under that valgrind. The SIGSEGV should happen inside valgrind itself, so use lldb to find the bug. ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Does valgrind work with Boehm garbage collector?
The execution recipe works for me on Fedora 28 using valgrind-3.14.0-7.fc28.x86_64. I omitted dsymutil. Why is it essential for you? It is not essential. Therefore omitting dsymutil will narrow the search for the problem(s). $ rpm -q clang clang-6.0.1-2.fc28.x86_64 Why there is no segmentation fault in your run? What version of clang? I showed that I used clang-6.0.1-2.fc28.x86_64. Also, the default on Mac is to use addresses greater than (1ul<<32). This catches some errors of storing an address in a 32-bit variable. The default on Fedora is to start using addresses at 4MiB, which saves 4 bytes of space in several important places, but in many cases avoids noticing the problem of storing an address in 32 bits. ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Does valgrind work with Boehm garbage collector?
On Mon, Feb 18, 2019 at 7:07 PM John Reiser wrote: > On 2/17/19, Peng Yu wrote: > > $ flex -o main.l.c main.l > > $ clang -I. -DGC_DEBUG -Wall -pedantic -g -c -o main.l.o main.l.c # > > rapidstring.h is in . > > $ clang main.l.o -lgc -lfl -o main.l.exe > > $ dsymutil main.l.exe > > What is 'dsymutil', where did you get it, what version? > What is the hardware architecture? That is just the command on Mac to generate the debug symbols. > > > The execution recipe works for me on Fedora 28 using > valgrind-3.14.0-7.fc28.x86_64. > I omitted dsymutil. Why is it essential for you? It is not essential. > > > $ ldd main.l.exe > linux-vdso.so.1 (0x7fffa7d9f000) > libgc.so.1 => /lib64/libgc.so.1 (0x7f255ef81000) > libc.so.6 => /lib64/libc.so.6 (0x7f255ebc2000) > libpthread.so.0 => /lib64/libpthread.so.0 (0x7f255e9a3000) > libdl.so.2 => /lib64/libdl.so.2 (0x7f255e79f000) > libatomic_ops.so.1 => /lib64/libatomic_ops.so.1 > (0x7f255e59c000) > libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f255e384000) > /lib64/ld-linux-x86-64.so.2 (0x7f255f2de000) > > $ rpm -qf /lib64/libgc.so.1 > gc-7.6.4-3.fc28.x86_64 > $ rpm -qf /usr/bin/flex > flex-2.6.1-7.fc28.x86_64 > $ rpm -q clang > clang-6.0.1-2.fc28.x86_64 Why there is no segmentation fault in your run? > > > $ valgrind ./main.l.exe ==23299== Memcheck, a memory error detector > ==23299== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. > ==23299== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright > info > ==23299== Command: ./main.l.exe > ==23299== > ==23299== Conditional jump or move depends on uninitialised value(s) > ==23299==at 0x4E4D166: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E49D21: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E4E786: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x403203: main (main.l:34) > ==23299== > ==23299== Conditional jump or move depends on uninitialised value(s) > ==23299==at 0x4E4D16B: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E49D21: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E4E786: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x403203: main (main.l:34) > ==23299== > ==23299== Use of uninitialised value of size 8 > ==23299==at 0x4E4CF57: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E4D171: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E49D21: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E4E786: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x403203: main (main.l:34) > ==23299== > ==23299== Conditional jump or move depends on uninitialised value(s) > ==23299==at 0x4E4CF66: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E4D171: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E49D21: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E4E786: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x403203: main (main.l:34) > ==23299== > ==23299== Use of uninitialised value of size 8 > ==23299==at 0x4E4CF9A: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E4D171: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E49D21: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E4E786: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x403203: main (main.l:34) > ==23299== > ==23299== Use of uninitialised value of size 8 > ==23299==at 0x4E491AA: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E446F6: ??? (in /usr/lib64/libgc.so.1.3.2) > ==23299==by 0x4E4D171: GC_push_all_eager (in
Re: [Valgrind-users] Does valgrind work with Boehm garbage collector?
==23299== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info ==23299== Command: ./main.l.exe ==23299== ==23299== Conditional jump or move depends on uninitialised value(s) ==23299== at 0x4E4D166: GC_push_all_eager (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E49D21: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E4E786: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E4D896: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E42C44: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E43348: ??? (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x4E5043B: GC_init (in /usr/lib64/libgc.so.1.3.2) ==23299== by 0x403203: main (main.l:34) After $ sudo dnf debuginfo-install /usr/lib64/libgc.so.1.3.2 then the messages look like: ==23530== Command: ./main.l.exe ==23530== ==23530== Conditional jump or move depends on uninitialised value(s) ==23530==at 0x4E4D166: GC_push_all_eager (mark.c:1583) ==23530==by 0x4E49D21: GC_with_callee_saves_pushed (mach_dep.c:322) ==23530==by 0x4E4E786: GC_push_regs_and_stack (mark_rts.c:772) ==23530==by 0x4E4E786: GC_push_roots (mark_rts.c:845) ==23530==by 0x4E4D896: GC_mark_some (mark.c:415) ==23530==by 0x4E42C44: GC_stopped_mark (alloc.c:702) ==23530==by 0x4E43348: GC_try_to_collect_inner (alloc.c:488) ==23530==by 0x4E5043B: GC_init (misc.c:1292) ==23530==by 0x403203: main (main.l:34) ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Does valgrind work with Boehm garbage collector?
On 2/17/19, Peng Yu wrote: $ flex -o main.l.c main.l $ clang -I. -DGC_DEBUG -Wall -pedantic -g -c -o main.l.o main.l.c # rapidstring.h is in . $ clang main.l.o -lgc -lfl -o main.l.exe $ dsymutil main.l.exe What is 'dsymutil', where did you get it, what version? What is the hardware architecture? The execution recipe works for me on Fedora 28 using valgrind-3.14.0-7.fc28.x86_64. I omitted dsymutil. Why is it essential for you? $ ldd main.l.exe linux-vdso.so.1 (0x7fffa7d9f000) libgc.so.1 => /lib64/libgc.so.1 (0x7f255ef81000) libc.so.6 => /lib64/libc.so.6 (0x7f255ebc2000) libpthread.so.0 => /lib64/libpthread.so.0 (0x7f255e9a3000) libdl.so.2 => /lib64/libdl.so.2 (0x7f255e79f000) libatomic_ops.so.1 => /lib64/libatomic_ops.so.1 (0x7f255e59c000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f255e384000) /lib64/ld-linux-x86-64.so.2 (0x7f255f2de000) $ rpm -qf /lib64/libgc.so.1 gc-7.6.4-3.fc28.x86_64 $ rpm -qf /usr/bin/flex flex-2.6.1-7.fc28.x86_64 $ rpm -q clang clang-6.0.1-2.fc28.x86_64 $ valgrind ./main.l.exe https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Does valgrind work with Boehm garbage collector?
Here is the output. It still fails. So I am not supposed to use valgrind when I use boehm gc? $ valgrind --tool=none ./main.l.exe < You might first try with --tool=none to see if the basis of valgrind+boehm > gc works. -- Regards, Peng ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Does valgrind work with Boehm garbage collector?
On Sun, 2019-02-17 at 20:51 -0600, Peng Yu wrote: > Hi, > > I have the follow flex code using Boehm garbage collector. > http://www.hboehm.info/gc/gcinterface.html > > The program is compiled with the following commands. > > $ flex -o main.l.c main.l > $ clang -I. -DGC_DEBUG -Wall -pedantic -g -c -o main.l.o main.l.c # > rapidstring.h is in . > $ clang main.l.o -lgc -lfl -o main.l.exe > $ dsymutil main.l.exe > > rapidstring.h can be downloaded here. > > https://raw.githubusercontent.com/boyerjohn/rapidstring/master/include/rapidstring.h > > The following commands show that without using valgrind, the program > runs OK. But if valgrind is used, the program will cause a > segmentation fault. > > Is it because valgrind does not work with a garbage collector? It would not be very amasing that memcheck (that replaces malloc) would conflict with something like Boehm gc, that for sure does strange things with malloc replacement itself. You might first try with --tool=none to see if the basis of valgrind+boehm gc works. Philippe ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
