Hello all, I have an android app i have been working on for almost a year. for the past couple months, I have been having problems with the app crashing for seemingly no reason. Everything is working and the framerate is smooth, but after a few minutes of testing on my android device the app crashes. After going through the whole debugging process in android studio the only thing i could spot was right when it crashes it displays Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xb19e4f68 in tid 14613 (RHIThread), pid 14516 (main). What does this error mean? How do i find what is making my app crash? and how do i fix it?
Did you found a solution? I’m getting the same random crash and have no idea what could be the cause
For me helped update Engine to 4.27
UE5 is crashing due to the same error, Did you try on UE5?
Hi. Can you provide backtrace from logcat?
A week ago I got similar error. I use UE4.27 from github
07-28 13:59:02.496 30045 30239 F libc : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x97e72f64 in tid 30239 (RHIThread), pid 30045
07-28 13:59:02.675 30388 30388 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
07-28 13:59:02.675 30388 30388 F DEBUG : Build fingerprint:
07-28 13:59:02.675 30388 30388 F DEBUG : Revision: '0'
07-28 13:59:02.675 30388 30388 F DEBUG : ABI: 'arm'
07-28 13:59:02.675 30388 30388 F DEBUG : Timestamp: 2022-07-28 13:59:02+0300
07-28 13:59:02.675 30388 30388 F DEBUG : pid: 30045, tid: 30239, name: RHIThread >>> com..<<<
07-28 13:59:02.675 30388 30388 F DEBUG : uid: 10570
07-28 13:59:02.675 30388 30388 F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x97e72f64
07-28 13:59:02.675 30388 30388 F DEBUG : r0 97e72f00 r1 000010c7 r2 b41bfda0 r3 00000000
07-28 13:59:02.675 30388 30388 F DEBUG : r4 d1e3952c r5 b41bfdac r6 b41bfda4 r7 00000000
07-28 13:59:02.675 30388 30388 F DEBUG : r8 00000001 r9 00000000 r10 b2a309d4 r11 b41bfdd0
07-28 13:59:02.675 30388 30388 F DEBUG : ip b2914534 sp b41bfd90 lr ac442d38 pc b1cef29c
00 pc 0afdd29c libUE4.so (FOpenGLDynamicRHI::OnVertexBufferDeletion(unsigned int)+752) (BuildId: 5a922ebdc24cf8cd161ceb420d6665f71ae95c62)
01 pc 0b0bea68 libUE4.so (UE4Function_Private::TFunctionRefCaller<TOpenGLBuffer<FOpenGLBaseVertexBuffer, 34962u, &(CachedBindArrayBuffer(unsigned int))>::~TOpenGLBuffer()::'lambda'(), void ()>::Call(void*)+36) (BuildId: 5a922ebdc24cf8cd161ceb420d6665f71ae95c62)
02 pc 0b022480 libUE4.so (FRHICommand<FRHICommandGLCommand, FRHICommandGLCommandString>::ExecuteAndDestruct(FRHICommandListBase&, FRHICommandListDebugContext&)+204) (BuildId: 5a922ebdc24cf8cd161ceb420d6665f71ae95c62)
03 pc 06c9a330 libUE4.so (FRHICommandListExecutor::ExecuteInner_DoExecute(FRHICommandListBase&)+2348) (BuildId: 5a922ebdc24cf8cd161ceb420d6665f71ae95c62)
04 pc 06cfb680 libUE4.so (FExecuteRHIThreadTask::DoTask(ENamedThreads::Type, TRefCountPtr<FGraphEvent> const&)+888) (BuildId: 5a922ebdc24cf8cd161ceb420d6665f71ae95c62)
05 pc 06cfad18 libUE4.so (TGraphTask<FExecuteRHIThreadTask>::ExecuteTask(TArray<FBaseGraphTask*, TSizedDefaultAllocator<32> >&, ENamedThreads::Type)+852) (BuildId: 5a922ebdc24cf8cd161ceb420d6665f71ae95c62)
06 pc 0553647c libUE4.so (FNamedTaskThread::ProcessTasksNamedThread(int, bool)+2352) (BuildId: 5a922ebdc24cf8cd161ceb420d6665f71ae95c62)
07 pc 055347f4 libUE4.so (FNamedTaskThread::ProcessTasksUntilQuit(int)+188) (BuildId: 5a922ebdc24cf8cd161ceb420d6665f71ae95c62)
08 pc 06d84588 libUE4.so (FRHIThread::Run()+152) (BuildId: 5a922ebdc24cf8cd161ceb420d6665f71ae95c62)
09 pc 05659e20 libUE4.so (FRunnableThreadPThread::Run()+164) (BuildId: 5a922ebdc24cf8cd161ceb420d6665f71ae95c62)
10 pc 0552dc68 libUE4.so (FRunnableThreadPThread::_ThreadProc(void*)+84) (BuildId: 5a922ebdc24cf8cd161ceb420d6665f71ae95c62)
I found FOpenGLDynamicRHI::OnVertexBufferDeletion in the engine source code. It located in ...\UnrealEngine\Engine\Source\Runtime\OpenGLDrv\Private\OpenGLCommands.cpp
Then I used UE_LOG to find crash point. In the code below, I point to the crash point.
Also, I print the value CachedStream.VertexBuffer->Resource. Most of the time it has values like -572662307 and it strongly seems like trash. But it works some time (± 1 min) and then crashes randomly.
if ((ActiveStreamMask & 0x1) &&
CachedStream.VertexBuffer &&
CachedStream.VertexBuffer->Resource == VertexBufferResource) <==== CHASH HERE!!!
{
FOpenGL::BindVertexBuffer(StreamIndex, 0, 0, 0); // brianh@nvidia: work around driver bug 1809000
CachedStream.VertexBuffer = nullptr;
CachedStream.Offset = 0;
CachedStream.Stride = 0;
}
It seems like CachedStream.VertexBuffer starts to point to address out of app memory volume. And android shoots down app
If a have right understood. Please correct me.
I’ve not found a fix yet. This is a big problem for me(( If someone have updates, please share it.
If ill get updates or find fix, ill write here
Sorry for my lousy en…
1 Like
I’m getting this same error on android with unreal engine 4.27. Anyone find a solution?
For me the android app for the game crashes only sometimes. Like 4 out of 10 times. It’s very easy to reproduce the crash through. I caught the logs through an adb app on my phone and it’s the same as mentioned here.
If anyone is still running into this… We ran into the same thing and running garbage collection a bit more aggressively (i.e. manually running it every 12 seconds right now) SEEMS to have worked around it.
GetWorld()->ForceGarbageCollection(true);
The issue seemed to be memory-related, so felt like that made sense to try. Not sure how much sense that makes but so far it seems to help.
In our case the issue seemed to be triggered by using K2_DrawMaterial(...).
that is because the destructor of TOpenGLBuffer<FOpenGLBaseVertexBuffer,…> push an RHI command to destroy the opengl resource, but the destructor is called in render thread. When the RHI command executing, the TOpenGLBuffer has already been destroyed, and OnVertexBufferDeletion called by FOpenGLBaseVertexBuffer::OnDelete needs to access the destroyed object, so SIGSEGV may occour.
one way to solve this problem is to pass “true” to the second parameter RunOnGLRenderContextThread function called in the destructor of TOpenGLBuffer, so that the desctructor will wait for the RHI command finish, but not all kind of buffer need to access TOpenGLBuffer object, it may cause some performace problem.
another way to solve it is to modify FOpenGLDynamicRHI::OnVertexBufferDeletion and FOpenGLStream, first add a GLuint property to it:
struct FOpenGLStream
{
FOpenGLVertexBuffer *VertexBuffer;
uint32 Stride;
uint32 Offset;
uint32 Divisor;
//add here
GLuint VertexBufferResource;
//add here
FOpenGLStream()
: VertexBuffer(0)
, Stride(0)
, Offset(0)
, Divisor(0)
//add here
, VertexBufferResource(0)
//add here
{}
};
the modify OnVertexBufferDeletion:
for (GLuint StreamIndex = 0; StreamIndex < NUM_OPENGL_VERTEX_STREAMS && ActiveStreamMask; StreamIndex++)
{
FOpenGLStream& CachedStream = RenderingContextState.VertexStreams[StreamIndex];
if ((ActiveStreamMask & 0x1) &&
CachedStream.VertexBuffer &&
//modify here, compare the GLuint property you add before instead of accessing the TOpenGLBuffer object.
CachedStream.VertexBufferResource == VertexBufferResource)
{
FOpenGL::BindVertexBuffer(StreamIndex, 0, 0, 0); // brianh@nvidia: work around driver bug 1809000
CachedStream.VertexBuffer = nullptr;
//do not forget to reset it
CachedStream.VertexBufferResource = 0;
CachedStream.Offset = 0;
CachedStream.Stride = 0;
}
ActiveStreamMask >>= 1;
}
then, you need to set the value of FOpenGLStream.VertexBufferResource wherever the FOpenGLStream VertexBuffer modified, for example:
void FOpenGLDynamicRHI::RHISetStreamSource(uint32 StreamIndex, FRHIVertexBuffer* VertexBufferRHI, uint32 Offset)
{
VERIFY_GL_SCOPE();
FOpenGLVertexBuffer* VertexBuffer = ResourceCast(VertexBufferRHI);
PendingState.Streams[StreamIndex].VertexBuffer = VertexBuffer;
//set VertexBufferResource
PendingState.Streams[StreamIndex].VertexBufferResource = VertexBuffer ? VertexBuffer->Resource : 0;
PendingState.Streams[StreamIndex].Stride = PendingState.BoundShaderState ? PendingState.BoundShaderState->StreamStrides[StreamIndex] : 0;
PendingState.Streams[StreamIndex].Offset = Offset;
}
and FOpenGLDynamicRHI::SetupVertexArrays
FOpenGLStream &CachedStream = ContextState.VertexStreams[StreamIndex];
FOpenGLStream &Stream = Streams[StreamIndex];
if (Stream.VertexBuffer)
{
uint32 Offset = BaseVertexIndex * Stream.Stride + Stream.Offset;
bool bAnyDifferent = //bitwise ors to get rid of the branches
(CachedStream.VertexBuffer != Stream.VertexBuffer) |
(CachedStream.Stride != Stream.Stride)|
(CachedStream.Offset != Offset);
if (bAnyDifferent)
{
check(Stream.VertexBuffer->Resource != 0);
FOpenGL::BindVertexBuffer(StreamIndex, Stream.VertexBuffer->Resource, Offset, Stream.Stride);
CachedStream.VertexBuffer = Stream.VertexBuffer;
//set VertexBufferResource
CachedStream.VertexBufferResource = Stream.VertexBuffer->Resource;
//
CachedStream.Offset = Offset;
CachedStream.Stride = Stream.Stride;
}
if (UpdateDivisors && CachedStream.Divisor != Divisor[StreamIndex])
{
FOpenGL::VertexBindingDivisor(StreamIndex, Divisor[StreamIndex]);
CachedStream.Divisor = Divisor[StreamIndex];
}
}
else
{
UE_LOG(LogRHI, Error, TEXT("Stream %d marked as in use, but vertex buffer provided is NULL (Mask = %x)"), StreamIndex, StreamMask);
FOpenGL::BindVertexBuffer(StreamIndex, 0, 0, 0);
CachedStream.VertexBuffer = nullptr;
//set VertexBufferResource
CachedStream.VertexBufferResource = 0;
//
CachedStream.Offset = 0;
CachedStream.Stride = 0;
}
and so on.
you can find usage of FOpenGLStream::VertexBuffer through your IDE to determine where to add code to set or reset FOpenGLStream::VertexBufferResource.
it will fix the crash