Skip to content
This repository has been archived by the owner on Nov 1, 2020. It is now read-only.

"pow3" received signal SIGSEGV , Segmentation fault. #5850

Closed
iarischenko opened this issue May 24, 2018 · 6 comments
Closed

"pow3" received signal SIGSEGV , Segmentation fault. #5850

iarischenko opened this issue May 24, 2018 · 6 comments

Comments

@iarischenko
Copy link
Contributor

I've compiled the pow3 test (.tests_downloaded/CoreCLR/Regressions/common/pow3) for ARM and x86_64. The test works fine at x86_64 and fails at ARM with SIGSEGV signal:

(gdb) bt
#0 EEType::get_IsValueType (this=0x1080000) at /dotnet/corert/src/Native/Runtime/inc/eetype.h:412
#1 0x00024984 in RhpBox (pObj=0x54aed8, pData=0xbefff1b0) at /dotnet/corert/src/Native/Runtime/gcrhenv.cpp:768
#2 0x00255d50 in S_P_CoreLib_System_Runtime_RuntimeExports__RhBox (pEEType=..., data=@0xbefff1b0: 86 'V') at /dotnet/corert/src/Runtime.Base/src/System/Runtime/RuntimeExports.cs:110
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

The InternalCalls.RhpNewFast(ptrEEType) at RuntimeExports.cs:108 returns
(gdb) p result
$1 = (Object &) @0x54aed8: {m_pEEType = 0x1080000}
and
m_pEEType is used as pointer in S_P_CoreLib_System_Runtime_RuntimeExports__RhBox in gcrhenv.cpp:768
and leads to SIGSEGV.

Could you help me to debug the issue?

@jkotas
Copy link
Member

jkotas commented May 24, 2018

This looks like a GC heap corruption. @BredPet Do this work on Tizen?

@iarischenko
Copy link
Contributor Author

Yes, We are working in one project at this moment.
I tried to compile and execute all of the CoreCLR tests for CoreRT.
271 out of 1973 finished with SIGSEGV signal.
Is it possible to rebuild the CoreRT with AddressSanitizer to detect such issues automatically?

@jkotas
Copy link
Member

jkotas commented May 28, 2018

AddressSanitizer is unlikely going to help you to trace this down. AddressSanitizer is for C/C++ programs. The .NET garbage collector is too level for AddressSanitizer.

The InternalCalls.RhpNewFast(ptrEEType) at RuntimeExports.cs:108 returns
(gdb) p result
$1 = (Object &) @0x54aed8: {m_pEEType = 0x1080000}

m_pEEType of this object should be same as pEEType argument passed into RhpNewFast. What is the argument of RhpNewFast when this happens? You should be able to tell by looking at the disassembly. If the argument is 0x1080000, it means there is codegen bug. If the argument is not 0x1080000, it means something went wrong inside RhpNewFast.

@iarischenko
Copy link
Contributor Author

cc @dotnet/arm32-contrib
cc @CarolEidt

@iarischenko
Copy link
Contributor Author

#5866

@iarischenko
Copy link
Contributor Author

The call
103 result = InternalCalls.RhpNewFastMisalign(ptrEEType);
returns ptrEEType as result of memory allocation and the result is used as object.
Looks like it is typo in the AllocFast.S BoxAlloc8Failed().

@jkotas jkotas closed this as completed May 30, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants