I'm working on a program containing an OpenGL view (using Ogre3D); this program hosts third-party plug-ins (namely, VST) which can have their own UI opened. Some plug-ins also use OpenGL for their UI and make the program crash in the Ogre Render System as soon as this plug-in-specific OpenGL UI is opened (no crash with other non-opengl plug-ins' UI).
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Thread 0 Crashed: com.apple.main-thread
0 GLEngine gleRunVertexSubmitImmediate + 722
1 GLEngine gleLLVMArrayFunc + 60
2 GLEngine gleSetVertexArrayFunc + 116
3 GLEngine gleDrawArraysOrElements_ExecCore + 1514
4 GLEngine glDrawElements_Exec + 834
5 libGL.dylib glDrawElements + 52
6 RenderSystem_GL.dylib Ogre::GLRenderSystem::_Render(...)...
...
22 Ogre Ogre::Root::renderOneFrame() + 30
23 com.mycompany.myapp MyOgreWidget::paint()
...
(apparently a third-party thread from the plug-in)
Thread 10: Dipatch queue: com.apple.opengl.glvmDoWork
0 libSystem.B.dylib mach_msg_trap + 10
1 libSystem.B.dylib mach_msg + 68
2 libCoreVMClient.dylib cvmsServ_BuildModularFunction + 195
3 libCoreVMClient.dylib CVMSBuildModularFunction + 98
4 libGLProgrammability.dylib glvm_deferred_build_modular(voi*) + 254
5 libSystem.B.dylib _dispatch_queue_drain + 249
6 libSystem.B.dylib _dispatch_queue_invoke + 50
7 libSystem.B.dylib _dispatch_worker_thread2 + 249
8 libSystem.B.dylib _pthread_wqthread + 390
9 libSystem.B.dylib start_wqthread + 30
I suspected that the OpenGL Context was not properly managed, either in Ogre3D or in the plug-in's UI, but it is not possible to access the plug-ins' render callbacks.
I tested with Ogre3D 1.7.1 and 1.7.3. My UI toolkit is Qt (version 4.6.3 and 4.7.4). Same issues with MacOSX and Windows.
I know other programs with OpenGL views which don't have this issue, even with the exact same plug-ins, I wonder how they handle such situations.
Any idea how to handle that?
Thanks for any help. All the best.
Any idea how to handle that?
I'd add a call to QGLWidget::doneCurrent right after finishing your own (=Ogre3D's) OpenGL work, and do a QGLWidget::makeCurrent before doing your own OpenGL work.
Related
I have had an app on the AppStore since 2011 and since then the app has gone through quite a few changes as you might expect, after the last change I have started receiving some crashes (I use Crashlytics) that seem to indicate that the source is CoreGraphics although it must be something that I'm doing wrong with it, and not the library itself, but since the crashes themselves do not contain any code that refers to my app it's a bit complicated to know what it could be.
I can't seem to be able to trigger this issue but some users can, I've checked and some of them had enough memory so it's not an out of memory issue afaik.
The only crashes I have received are all this one in particular so it's not a red herring due to some memory issues that may trigger false positives. The app is constantly used and tested with Address sanitizer on so it should catch all of these.
I'm fairly well versed in C++ (the main language of the app) but know just enough Objective-C to get things done so I was wondering if I am missing something or if there is a way to debug this, since I wouldn't even know where to start.
Since I can't trigger the issue, and I can't see where it happens, I can't think of any way of sorting this out.
What would be the best way of debugging this, how do people approach this?
Crashed: com.apple.main-thread
0 libsystem_platform.dylib 0x184079b80 _platform_memmove + 176
1 CoreGraphics 0x185bc81f8 decode_data + 12740
2 CoreGraphics 0x185bc81f8 decode_data + 12740
3 CoreGraphics 0x185d982f4 img_decode_read + 2032
4 CoreGraphics 0x185d9bffc img_alphamerge_read + 548
5 CoreGraphics 0x185d9f818 img_data_lock + 7048
6 CoreGraphics 0x185d9dc38 CGSImageDataLock + 184
7 CoreGraphics 0x185bbe704 ripc_AcquireRIPImageData + 308
8 CoreGraphics 0x185db287c ripc_DrawImage + 644
9 CoreGraphics 0x185da2678 CGContextDrawImageWithOptions + 632
10 QuartzCore 0x188335f7c CA::Render::(anonymous namespace)::create_image_by_rendering(CGImage*, CGColorSpace*, unsigned int, double) + 1232
11 QuartzCore 0x188336f60 CA::Render::(anonymous namespace)::create_image_from_rgb_image(CGImage*, CGColorSpace*, unsigned int, double) + 676
12 QuartzCore 0x1883358e4 CA::Render::create_image(CGImage*, CGColorSpace*, unsigned int, double) + 900
13 QuartzCore 0x188338584 CA::Render::copy_image(CGImage*, CGColorSpace*, unsigned int, double, double) + 472
14 QuartzCore 0x18843ebcc -[CALayer(CALayerPrivate) _copyRenderLayer:layerFlags:commitFlags:] + 632
15 QuartzCore 0x1884434b0 CA::Layer::commit_if_needed(CA::Transaction*, void (*)(CA::Layer*, unsigned int, unsigned int, void*), void*) + 444
16 QuartzCore 0x1883a7dcc CA::Context::commit_root(CA::Layer*, void*) + 44
17 QuartzCore 0x188366fd8 x_hash_table_foreach + 72
18 QuartzCore 0x1883a8674 CA::Context::commit_transaction(CA::Transaction*) + 2208
19 QuartzCore 0x1883ce340 CA::Transaction::commit() + 540
20 QuartzCore 0x1883cf180 CA::Transaction::observer_callback(__CFRunLoopObserver*, unsigned long, void*) + 92
21 CoreFoundation 0x1843ff8b8 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 32
22 CoreFoundation 0x1843fd270 __CFRunLoopDoObservers + 412
23 CoreFoundation 0x1843fd82c __CFRunLoopRun + 1292
24 CoreFoundation 0x18431e2d8 CFRunLoopRunSpecific + 436
25 GraphicsServices 0x1861aff84 GSEventRunModal + 100
26 UIKit 0x18d8cb880 UIApplicationMain + 208
27 (MyAppName) 0x1010cb280 main (main.m:14)
28 libdyld.dylib 0x183e4256c start + 4
I have problem with debugging Qt5.4 application on win7. It gives following error by message-Box (without debug mode, the application runs without any problem):
The inferior stopped because it triggered an exception.
Stopped in thread 18 by: Exception at 0x7718c42d, code: 0xe06d7363: C++ exception, flags=0x1 (execution cannot be continued) (first chance).
call stack:
0 RaiseException KERNELBASE 0x7718c42d
1 DllGetClassObject vsfilter 0x3a6aca71
2 DirectVobSub vsfilter 0x3a64fa11
3 vsfilter 0x3a632c0b
4 DllGetClassObject vsfilter 0x3a6c90bc
5 vsfilter 0x3a636da0
6 CSTInnerUnknown::AddRef sync.cxx 225 0x753deddf
7 DllGetClassObject vsfilter 0x3a6aab2f
8 CRWLock::AcquireReaderLock rwlock_ole32.cxx 3099 0x753da471
9 DllGetClassObject vsfilter 0x3a6aab2f
10 DllGetClassObject vsfilter 0x3a6ce866
11 DllGetClassObject vsfilter 0x3a6cbd4b
12 DispatchMessageWorker USER32 0x759b77c4
13 wcscpy_s USER32 0x75a1a61d
14 _RtlUserThreadStart ntdll 0x77919f45
It might be a little bit late, but I had the same error.
See, I don't see your code, so I cant say what your problem was exactly but I can say what solved mine:
I had a Gaussian-filter of open-cv running, which was clearing my picture from noise. It had the size of 3x3. As soon as I adjusted the size to 10x10 for testing, I got the same exception.
So maybe you have also a to big filter or something. To say it exactly I would need more code example.
But anyway this maybe helps someone else!
I am creating a lot of QWebViews which each create QThreads. The problem is that I am running out of stack space to create more threads. Therefore, I was wondering if there is a way to clean up existing threads. To be clear, I am not the one creating these threads: Qt creates the threads when I show a QWebView.
Most of the threads (about 400/500) have the exact same stack:
0 ntdll!RtlEnableEarlyCriticalSectionEventCreation C:\Windows\system32\ntdll.dll 0 0x770b013d
1 KERNEL32!GetVolumePathNamesForVolumeNameA C:\Windows\syswow64\kernel32.dll 0 0x766d1a2c
2 USER32!MessageBoxA C:\Windows\syswow64\user32.dll 0 0x74cd086a
3 QEventDispatcherWin32::processEvents qeventdispatcher_win.cpp 831 0x69de3948
4 QEventLoop::processEvents qeventloop.cpp 149 0x69dbf0c5
5 QEventLoop::exec qeventloop.cpp 204 0x69dbf223
6 QThread::exec qthread.cpp 501 0x69cd412b
7 QThread::run qthread.cpp 568 0x69cd4283
8 QThreadPrivate::start qthread_win.cpp 346 0x69cd54d1
9 msvcrt!_itow_s C:\Windows\syswow64\msvcrt.dll 0 0x75401287
10 msvcrt!_endthreadex C:\Windows\syswow64\msvcrt.dll 0 0x75401328
11 KERNEL32!BaseCleanupAppcompatCacheSupport C:\Windows\syswow64\kernel32.dll 0 0x766d339a
12 ntdll!RtlpNtSetValueKey C:\Windows\system32\ntdll.dll 0 0x770c9ef2
13 ntdll!RtlpNtSetValueKey C:\Windows\system32\ntdll.dll 0 0x770c9ec5
14 ?? 0
Is there any way to clean them up?
Since I realized that the thread was allocated for the NetworkManager, I created a global NetworkManager instance and set it to the NetworkAccessManager of every QWebView. This allowed it to reuse the same group of threads for all of the pages and thus doesnt leave many threads laying around.
I use libcurl for FTP works and it works fine but if left idle for some time it just crashes. Here is the backtrace which despite reading it for some time I cannot make sense of what is wrong. The trace does not show where in my functions crash originates and so am left orphan here by debugger. I use threads if that add value
Compiler is GCC 4.7 on Linux
0 0x00007fff8e09b524 addbyter /home/stefano/Desktop/myproject/curl-7.33.0/lib/mprintf.c 914
1 0x00007fff8e09a32f dprintf_formatf /home/stefano/Desktop/myproject/curl-7.33.0/lib/mprintf.c 572
2 0x00007fff8e09b5a4 curl_mvsnprintf /home/stefano/Desktop/myproject/curl-7.33.0/lib/mprintf.c 932
3 0x00007fff8e089510 Curl_failf /home/stefano/Desktop/myproject/curl-7.33.0/lib/sendf.c 152
4 0x00007fff8e07dbf4 Curl_resolv_timeout /home/stefano/Desktop/myproject/curl-7.33.0/lib/hostip.c 618
5 0x00007fff78012bf8 ??
6 0x000000c300000016 ??
7 0x00007fff8e0d3604 ??
8 0x0000000000000002 ??
9 0x00000000001b7740 ??
10 0x0000000000000000 ??
UPDATE 1
Run it again under debugger and met a crash at the line
FILE *fd;
fd = fopen(files[i].c_str(), "rb"); //<---here goes the crash!
files[i].c_str() is supposed to give const* char from wxString
The new BT is
0 0x00007fff8e08952a Curl_failf /home/stefano/Desktop/myproject/curl-7.33.0/lib/sendf.c 154
1 0x00007fff8e07dbf4 Curl_resolv_timeout /home/stefano/Desktop/myproject/curl-7.33.0/lib/hostip.c 618
2 0x00007fff780158c8 ??
3 0x00000000001b7730 ??
4 0x00007fff78009808 ??
5 0x00007fff78015e79 ??
6 0x00007fff78009808 ??
7 0x00007fff8c8a04a0 ??
8 0x00007fff8e0c84ca ftp_multi_statemach /home/stefano/Desktop/myproject/curl-7.33.0/lib/ftp.c 3113
Such error can be caused if you're using curl in non-main thread. When curl can't resolve dns entry, it sends a signal (by default) to interrupt a thread by timeout. Signals are not thread safe and can cause a crash. You should compile libcurl with --enable-threaded-resolver or with support of c-ares.
Also for me it was useful to disable signals at all
curl_easy_setopt(curl, CURLOPT_NOSIGNAL, 1)
I'm running on the Mavericks GM with Xcode 5.0.1 GM. The OS X SDK used to compile against doesn't seem to matter. I've tried recompiling my company's software with both the 10.8 and 10.9 SDKs. I get the same result compiling for Debug and Release. Oddly enough, if I compile on 10.7 or 10.8 and bring the binaries over to a 10.9 machine, everything works fine.
The software I work on is written in C++ and runs about 600K lines of code. Nothing in our codebase uses lbxpc directly. Some of the biggest external libraries used:
Qt 4.8.5
Boost 1.49.0
OpenCL (dynamically loaded at runtime)
OpenEXR
Growl 1.2.1
Whenever the crash happens, it's at a seemingly random place in the application's main thread.
Has anyone else run into this issue? If so, what was the cause, and how did you fix it?
Disassembly of where the crash happens:
0x7fff8f2e1e3b: leaq 98519(%rip), %rax ; "Bug in libxpc: Domain environment context has overflowed maximum inline message size."
0x7fff8f2e1e42: movq %rax, -389938449(%rip) ; gCRAnnotations + 8
0x7fff8f2e1e49: ud2 <-- crash
Backtrace from lldb:
* thread #4: tid = 0x122764, 0x00007fff8f2e1e49 libxpc.dylib`_xpc_domain_serialize + 496, queue = 'com.apple.root.default-overcommit-priority, stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
frame #0: 0x00007fff8f2e1e49 libxpc.dylib`_xpc_domain_serialize + 496
frame #1: 0x00007fff8f2e18ca libxpc.dylib`_xpc_dictionary_serialize_apply + 84
frame #2: 0x00007fff8f2e1497 libxpc.dylib`_xpc_dictionary_apply_node_f + 105
frame #3: 0x00007fff8f2e16af libxpc.dylib`_xpc_dictionary_serialize + 161
frame #4: 0x00007fff8f2e1184 libxpc.dylib`_xpc_serializer_pack + 423
frame #5: 0x00007fff8f2e0f81 libxpc.dylib`_xpc_pipe_pack_message + 118
frame #6: 0x00007fff8f2e0985 libxpc.dylib`xpc_pipe_routine + 99
frame #7: 0x00007fff8f2dff2a libxpc.dylib`_xpc_runtime_init_once + 827
frame #8: 0x00007fff9076c2ad libdispatch.dylib`_dispatch_client_callout + 8
frame #9: 0x00007fff9076c21c libdispatch.dylib`dispatch_once_f + 79
frame #10: 0x00007fff8f2e4144 libxpc.dylib`_xpc_connection_init + 64
frame #11: 0x00007fff8f2e40f6 libxpc.dylib`_xpc_connection_resume_init + 14
frame #12: 0x00007fff9076c2ad libdispatch.dylib`_dispatch_client_callout + 8
frame #13: 0x00007fff9076e09e libdispatch.dylib`_dispatch_root_queue_drain + 326
frame #14: 0x00007fff9076f193 libdispatch.dylib`_dispatch_worker_thread2 + 40
frame #15: 0x00007fff922f0ef8 libsystem_pthread.dylib`_pthread_wqthread + 314
frame #16: 0x00007fff922f3fb9 libsystem_pthread.dylib`start_wqthread + 13
Update with some more information:
I just found out something rather interesting. This issue only happens when the application is launched by Xcode. If I launch it via lldb on the command line, this crash does not occur. Likewise, if I double click on it in Finder, the issue does not occur.