A couple of users are reporting that sometimes when my app crashes, the receive a message box like this:
The lldb command requires the command line developer tools. Would you like to install the tools now?
The crash (SIGABRT) looks like a race condition somewhere in my code. But why is it seemingly trying to launch lldb when this happens? I've never seen anything like this, it seems fairly isolated to a couple of users, and I can't reproduce locally - although I do have the developer tools installed.
It's almost like JIT debugging in a .NET, but I've never heard of that in Cocoa and my Google searches on this are fruitless.
Edit:
If I run ps we can see both the Problem Reporter and Install Command Line Developer Tools:
19582 0.0 0.4 2568032 33224 ?? S 10:22AM 0:00.72 /System/Library/CoreServices/Problem Reporter.app/Contents/MacOS/Problem Reporter
19579 0.0 0.2 2531748 13276 ?? S 10:22AM 0:00.16 /System/Library/CoreServices/Install Command Line Developer Tools.app/Contents/MacOS/Install Command Line Developer Tools
There is nothing else suspicious in the list. If I run ps with the -f switch, I can see that the parent process for Install Command Line Developer Tools is launchd.
The CrashReporter tool that Apple ships does not try to connect a debugger to crashed programs. There used to be an option to do that in Leopard or thereabouts (not on by default), but that capability was turned off by Mountain Lion (maybe even SnowLeopard). I don't think it is possible to install any Xcode with lldb in it on Leopard, so it seems unlikely it is an old Apple CrashReporter that is trying to hook the debugger up to the app. OTOH, it is possible to replace the Apple's CrashReporter tool with another that could do this, and some third party vendors do do this. Maybe that is what is going on?
If you got the users who see this to send you the output of "ps auwwx" when the dialog box is present, you might be able to spot the culprit.
Related
I'm trying to use the Atom IDE to make some Haxe project on my new Mac (as a Windows user, I'm discovering this world), and I install the package "haxe" to do this. Until there, all is perfect (great jobs to them \o/), and I can compile an swf :).
But I have a little problem, even with the "-debug", all my traces are in the swf, not on the output console (terminal if I run from it, or output panel on Atom). Maybe I've forget to do/install/init something ?
I have a testing setup which runs an Application on OS X with a varying set of parameters, if/when the program crashes it's relaunched and continues from where it left off. However when the Application crashes OS X raises the “Application quit unexpectedly” dialog, I'd rather avoid this as it clutters the machine. Is there a way to inhibit this dialog from opening without modifying the source of the Application? If it's of any help in honing solutions the scripting setup is written in Python.
As an example, on Windows I handle the GPF dialog like this:
SEM_NOGPFAULTERRORBOX = 0x0002
ctypes.windll.kernel32.SetErrorMode(SEM_NOGPFAULTERRORBOX);
Ideally there'd be something similar I could use on OS X.
Thanks.
With the developer tools (Xcode, etc.) installed, you get a tool called CrashReporterPrefs. This is basically an interface to some plist file that sets globally how you want crashes handled. Probably not exactly what you're looking for, but if you control the deployment environment it might help.
There must be other options because Google products, like Sketchup, override the default handler and install their own crash reporter. My guess is that they register signal handlers for SIGBUS, SIGSEGV, etc. (see man 2 sigaction) and somehow mask the crash from MacOSX... but I'm speculating here.
I'll let others ask the question on why you can't fix the crash instead. :-)
I have an app that updates itself over the internet, and the updated copy won't run on PowerPC machines (G5) running Leopard (10.5.8). Double-clicking the app produces a message saying "You can't open the application "appname" because it is not supported on this architecture." But here's the weird part: if I duplicate the app using the Finder or using a cp -R command, then the duplicate runs fine! And yet, if I do ls -laeR on both apps, the results are identical. I restarted the machine, and the difference between the two copies was still there.
Sometimes, renaming the app made it run. After a few tries, I managed to rename it back to the original name and still have it run.
If this was just on one machine, I'd dismiss it as disk corruption, cosmic rays, or a voodoo hex, but it was reported by a customer and then I reproduced it on my own machine.
Any ideas what could cause this behavior?
It turns out that the Launch Services database had somehow flagged the app as unsupported, which I verified by using the semi-secret lsregister command line tool to dump the database. Anything that would change the mod date of the app, such as touch, sufficed to make Launch Services wake up and smell the coffee.
Sounds to me like an extended attribute or some other aspect that isn't being carried over to the duplicate of the program files.
Maybe try looking into running the xattr command on the output of ls -laeR on the app bundle?
I have a console application (written in VB6 ) which is behaving strangely on my machine. I kick it off from the command line and what should be a two minute job drops straight back to the prompt - if I run this on another machine the executable will sit and wait until the job finishes before returning control back to the prompt. If I check process explorer I can see that the executable is running as a background process and other than this strange background-ness is running as expected.
Any thoughts on why this could be happening? (Running on 32-bit Windows XP Pro SP3.)
It's totally unclear whether this is an application you wrote and have the source code for. If that's the case, you need to get in and start debugging. At the least, use OutputDebugString to send information about what's going on to any number of potential viewers. Taking that a step further, consider rewiring the app using the Console module I wrote, along with vbAdvance to recompile. This combination will allow you the full power of the VB6 IDE to debug within. No more guessing about what's going on.
Then again, if it's not your app, I'm not sure what VB6 has to do with it and wish you the best of luck trying to figure out what's up.
It sounds to me as though the app isn't being recognised as a console app on one of your machines. Console apps weren't officially supported in VB6, although there are some well-known hacks for creating them (particularly the free add-in vbAdvance). Possibly your console app is a bit unreliable? If Windows thinks your app is a GUI rather than a console app, it won't wait for it to finish.
As a pragmatic workaround: try launching with start /wait rather than just using the exename. That forces the command prompt to wait for the program to finish, whether it's a GUI app or a console app.
Sounds like an error is occurring that is being 'swallowed' by the application. Do you have the source code?
Errors in VB6 apps are often due to some COM component not installed and/or registered.
Download SysInternals Process Monitor and this will show up accesses to ProgIDs that fail (uninstalled/unregistered COM components).
Check out: Process Monitor - Hands-On Labs and Examples.
Have you checked permissions? Is the application accessing any network based resources?
I've got a user reporting crashes in my Mac OS X application, and their console logs report the following:
Symbolication warning: error parsing FDE at 0x100052649 in:\n
Does anyone have any insight into what this might be? I assume that somehow the symbols have been stripped from my app in a way that gets in the way of Mac OS X's crash reporter, but I've not seen it before.
I can honestly say that I have never seen this one before. I have seen a number of other dynamic linking problems just not this one. If the user is amenable to helping you with this defect, you might want to write a shell script to enable some dynamic linking environment variables and then launch your application.
#! /bin/bash
export DYLD_PRINT_LIBRARIES=1
export DYLD_PRINT_LIBRARIES_POST_LAUNCH=1
export DYLD_PRINT_APIS=1
export DYLD_PRINT_BINDINGS=1
export DYLD_PRINT_DOFS=1
open -a Console.app > /tmp/link-log 2>&1
The output log might provide some hint as to what is going on. You could also capture the output of otool and other command line utilities to check for unexpected libraries and what not.
You might want to google Symbolication to get a better handle of what is going on here. I came across an interesting chunk of code from Darwin that points this to a dynamic symbol lookup warning. There is also a utility called Shark that may be of interest as well.
Good luck...
I just found this topic via Google because I'm having the same problem. The StarCraft installer crashes immediately. It points to /usr/libexec/oah/translate, which seems to work perfectly well. My guess is this has something to do with the fact the computer it doesn't work on runs iDeneb 1.3 (aka Mac OS X 86 for use on non-Apple hardware), whereas the computer that can run the application just fine has a genuine version of Leopard.