Thread overview
[Bug 233] crash in memory allocator
Jul 15, 2016
Sebastien Alaiwan
Jul 15, 2016
Sebastien Alaiwan
Jul 15, 2016
Iain Buclaw
Jul 15, 2016
Sebastien Alaiwan
Aug 22, 2016
Sebastien Alaiwan
Aug 22, 2016
Iain Buclaw
Aug 23, 2016
Sebastien Alaiwan
Jul 15, 2017
Sebastien Alaiwan
July 15, 2016
http://bugzilla.gdcproject.org/show_bug.cgi?id=233

--- Comment #1 from Sebastien Alaiwan <sebastien.alaiwan@gmail.com> ---
Here's what I get in GDB:

Program received signal SIGSEGV, Segmentation fault.
__memset_sse2 () at ../sysdeps/x86_64/multiarch/../memset.S:80
80      ../sysdeps/x86_64/multiarch/../memset.S: No such file or directory.
(gdb) bt
#0  __memset_sse2 () at ../sysdeps/x86_64/multiarch/../memset.S:80
#1  0x0000000000469120 in _d_arraysetlengthT (ti=<optimized out>,
newlength=newlength@entry=2226, p=p@entry=0x7fffffffd7c0) at
../../../../src/libphobos/libdruntime/rt/lifetime.d:1617
#2  0x00000000004053ce in D main (args=...) at fuzzalloc.d:25

-- 
You are receiving this mail because:
You are watching all bug changes.
July 15, 2016
http://bugzilla.gdcproject.org/show_bug.cgi?id=233

--- Comment #2 from Sebastien Alaiwan <sebastien.alaiwan@gmail.com> ---
By the way, here's my version.

$ gdc --version
gdc (Debian 5.4.0-6) 5.4.0 20160609
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I'm unable to reproduce the issue with a manually compiled gdc+phobos from git
("gdc-5" branch) ; it might depend on build options, or it might already be
fixed.
(BTW does anybody knows how to tell the git version which was used to build a
debian gdc?)

-- 
You are receiving this mail because:
You are watching all bug changes.
July 15, 2016
http://bugzilla.gdcproject.org/show_bug.cgi?id=233

--- Comment #3 from Iain Buclaw <ibuclaw@gdcproject.org> ---
I can't reproduce it in master, which is using the next version of druntime compared to what is shipped in Debian.

Is the segfault consistently in that location?

-- 
You are receiving this mail because:
You are watching all bug changes.
July 15, 2016
http://bugzilla.gdcproject.org/show_bug.cgi?id=233

--- Comment #4 from Sebastien Alaiwan <sebastien.alaiwan@gmail.com> ---
Yes, it seems so.

(gdb) run
Starting program: /home/ace/projects/fuzzing/crashed/fuzzalloc
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".0
100000
200000


Program received signal SIGSEGV, Segmentation fault.
__memset_sse2 () at ../sysdeps/x86_64/multiarch/../memset.S:80
80      ../sysdeps/x86_64/multiarch/../memset.S: No such file or directory.
(gdb) bt
#0  __memset_sse2 () at ../sysdeps/x86_64/multiarch/../memset.S:80
#1  0x0000000000469120 in _d_arraysetlengthT (ti=<optimized out>,
newlength=newlength@entry=8760, p=p@entry=0x7fffffffbd70) at
../../../../src/libphobos/libdruntime/rt/lifetime.d:1617
#2  0x00000000004053ce in D main (args=...) at fuzzalloc.d:25

(gdb) run
Starting program: /home/ace/projects/fuzzing/crashed/fuzzalloc
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".0
100000
200000
300000
400000
500000
600000


Program received signal SIGSEGV, Segmentation fault.
__memset_sse2 () at ../sysdeps/x86_64/multiarch/../memset.S:80
80      ../sysdeps/x86_64/multiarch/../memset.S: No such file or directory.
(gdb) bt
#0  __memset_sse2 () at ../sysdeps/x86_64/multiarch/../memset.S:80
#1  0x0000000000469120 in _d_arraysetlengthT (ti=<optimized out>,
newlength=newlength@entry=2186, p=p@entry=0x7fffffffd580) at
../../../../src/libphobos/libdruntime/rt/lifetime.d:1617
#2  0x00000000004053ce in D main (args=...) at fuzzalloc.d:25

-- 
You are receiving this mail because:
You are watching all bug changes.
August 22, 2016
http://bugzilla.gdcproject.org/show_bug.cgi?id=233

--- Comment #5 from Sebastien Alaiwan <sebastien.alaiwan@gmail.com> ---
I was hoping recent phobos updates that made their way in debian-gdc would
solve these issues.
They don't ; I can still reproduce this crash with recent debian-gdc compilers.

It's not deterministic, sometimes it doesn't seem to happen at all ; sometimes
it gets killed by OOM killer ...
By the way, we might have found a workaround: by rounding all of our
allocations to the next multiple of 64, it seems not to happen.

$ gdc fuzzalloc.d -o fuzzalloc && ./fuzzalloc 12345
0
100000
200000
300000
400000
500000
[1]    9162 segmentation fault  ./fuzzalloc 12345

$ gdc fuzzalloc.d -o fuzzalloc && ./fuzzalloc 12345
0
100000
200000
300000
400000
500000
600000
700000
800000
900000
1000000
1100000
1200000
1300000
1400000
1500000
1600000
1700000
1800000
1900000
2000000
2100000
2200000
2300000
2400000
2500000
2600000
2700000
2800000
2900000
3000000
3100000
[1]    9196 segmentation fault  ./fuzzalloc 12345
Real: 24,57s User: 7,86s System: 15,35s Percent: 94% Cmd: ./fuzzalloc 12345

$ gdc --version
gdc (Debian 6.1.1-11) 6.1.1 20160802
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

-- 
You are receiving this mail because:
You are watching all bug changes.
August 22, 2016
http://bugzilla.gdcproject.org/show_bug.cgi?id=233

--- Comment #6 from Iain Buclaw <ibuclaw@gdcproject.org> ---
Does this happen on all systems, or just a few?  Have you eliminated bad memory - for instance, if memtester fails then you know it isn't druntime.

-- 
You are receiving this mail because:
You are watching all bug changes.
August 23, 2016
http://bugzilla.gdcproject.org/show_bug.cgi?id=233

--- Comment #7 from Sebastien Alaiwan <sebastien.alaiwan@gmail.com> ---
It consistently happens at least on 4 different Debian (stretch) PCs:
- two DELL desktop at my office (16Gb of RAM each)
- one production HP bladeserver (72Gb of RAM)
- my home PC (8Gb of RAM).

I think we can eliminate bad memory.

We first encountered the problem in the bladeserver, with a real program (our
production system). It's a blocking issue to us so we had to find a workaround
(round memory allocations to the next multiple of 64).
In the meantime, I found a way to reproduce this crash with a reduced test case
(the one I posted here).

However, the reduced test case isn't deterministic, and I don't get the crash at each run (I would say, 1/3 of the times).

-- 
You are receiving this mail because:
You are watching all bug changes.
July 15, 2017
https://bugzilla.gdcproject.org/show_bug.cgi?id=233

Sebastien Alaiwan <sebastien.alaiwan@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #8 from Sebastien Alaiwan <sebastien.alaiwan@gmail.com> ---
OK, I can't reproduce it anymore.
Seems like the problem was fixed (maybe an issue in core.gc?).
I'm closing this.

-- 
You are receiving this mail because:
You are watching all bug changes.