runtime: Double free or corruption on Raspbian
After the move from .NETCore 2.0 to 2.1 this started happening very frequently.
PowerShell running on Raspberry Pi 3 Model B (“Raspbian GNU/Linux 9 (stretch)”)
crashes with:
*** Error in "pwsh": double free or corruption (fasttop): 0x6e800fe0 ***
stack from gdb:
Thread 6076 "pwsh" received signal SIGABRT, Aborted.
[Switching to Thread 0x63647450 (LWP 32303)]
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
dotnet/coreclr#1 0x76bc2824 in __GI_abort () at abort.c:89
dotnet/coreclr#2 0x76bfbf78 in __libc_message (do_abort=do_abort@entry=2, fmt=<optimized out>) at ../sysdeps/posix/libc_fatal.c:175
dotnet/coreclr#3 0x76c02ad4 in malloc_printerr (action=<optimized out>, str=0x76cb5120 "double free or corruption (fasttop)", ptr=<optimized out>, ar_ptr=<optimized out>) at malloc.c:5049
dotnet/coreclr#4 0x76c03514 in _int_free (av=0x6e800010, p=0x6e800fd8, have_lock=<optimized out>) at malloc.c:3905
dotnet/coreclr#5 0x768381e0 in HeapFree () from /home/pi/PSP3_2/libcoreclr.so
dotnet/coreclr#6 0x765fd0aa in EEHeapFreeInProcessHeap(unsigned int, void*) () from /home/pi/PSP3_2/libcoreclr.so
dotnet/coreclr#7 0x76532c70 in operator delete(void*) () from /home/pi/PSP3_2/libcoreclr.so
dotnet/coreclr#8 0x765adff0 in Thread::intermediateThreadProc(void*) () from /home/pi/PSP3_2/libcoreclr.so
dotnet/coreclr#9 0x76851966 in CorUnix::CPalThread::ThreadEntry(void*) () from /home/pi/PSP3_2/libcoreclr.so
dotnet/coreclr#10 0x76ecefc4 in start_thread (arg=0x63647450) at pthread_create.c:335
dotnet/coreclr#11 0x76c66c68 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:76 from /lib/arm-linux-gnueabihf/libc.so.6
Can share the core file with above stack.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 3
- Comments: 72 (30 by maintainers)
Commits related to this issue
- Add linux-arm workaround for https://github.com/dotnet/coreclr/issues/18486 — committed to JustArchiNET/ArchiSteamFarm by JustArchi 6 years ago
- Fix a PAL spin lock issue Fixes https://github.com/dotnet/coreclr/issues/18486 - Lock release needs to be at least volatile — committed to kouvel/coreclr by kouvel 6 years ago
- Fix a PAL spin lock issue Fix for https://github.com/dotnet/coreclr/issues/18486 - Lock release needs to be at least volatile — committed to kouvel/coreclr by kouvel 6 years ago
- Fix a PAL spin lock issue Fix for https://github.com/dotnet/coreclr/issues/18486 - Lock release needs to be at least volatile — committed to kouvel/coreclr by kouvel 6 years ago
- Fix a PAL spin lock issue (#19604) Fix for https://github.com/dotnet/coreclr/issues/18486 - Lock release needs to be at least volatile — committed to dotnet/coreclr by kouvel 6 years ago
- Fix a PAL spin lock issue (#62) Fix for https://github.com/dotnet/coreclr/issues/18486 - Lock release needs to be at least volatile coreclr master PR: https://github.com/dotnet/coreclr/pull/19604 — committed to dotnet/diagnostics by kouvel 6 years ago
- Fix a PAL spin lock issue (#19606) Fixes https://github.com/dotnet/coreclr/issues/18486 - Lock release needs to be at least volatile — committed to dotnet/coreclr by kouvel 6 years ago
- Fix a PAL spin lock issue (#19606) Fixes https://github.com/dotnet/coreclr/issues/18486 - Lock release needs to be at least volatile — committed to dotnet-maestro-bot/coreclr by kouvel 6 years ago
Looks like this DID make it into 2.1.5
2018-08-28 - [9663131aec] Fix a PAL spin lock issue (#19606)
The fix is currently targeting a September release for 2.1. Closing based on https://github.com/dotnet/coreclr/pull/19606.
I’ve got similar reports from users running my
netcoreapp2.1
project on Raspbian, so it looks like a global issue, not just something pwsh-related. They also claim that it didn’t happen before onnetcoreapp2.0
. I didn’t get reports from other platforms and setups, so it looks arm or raspbian-related.Sadly I don’t have any stacktraces, only generic reports. Just wanted to confirm this one with entirely different project, thanks.