skiptype

@pestbarn.me


Ask me anything  


Reblogged from maniacalrage
maniacalrage: Best Dialog on Earth If you’ve put a “Crash” button in your dialog, you’ve failed. Then again, it does make application crashes more like a little minigame… Do I give up and burn it all or do I try to continue and see what this apocalyptic world looks like? (Spoiler: Every time I’ve ever hit “Continue” the app has crashed moments later.) I showed this to a hacker-happy friend of mine, who gave me a lengthy comment on it. Well, not really. If an assertion fails, it may be due to a memory corruption bug that incidentally overwrote some internal variable with a bogus value, “crashing” (e.g probably calling the abort() function) and thus producing a core-dump that may be inspected with a debugger is actually quite sane behavior in that case. Normally abort() would be called immediately upon a failed assertion, the only difference in this case is giving the option to continue anyway to be able to (possibly) save your work. I’d use “save as” in case the save gets corrupted / incomplete though. Fortunately there’s a way to “beat the game” though. Just attach to the process with gdb and use the generate-core-file command, or the gcore utility. With enough assembly & reverse-engineering skills you could probably even parse out the relevant data structures in the memory dump and be able to restore any unsaved changes to your project from that. ;) ‎(If it wasn’t obvious from context, I might add that this should be done while the popup is showing and before pressing continue, in case the application crashes.)

maniacalrage:

Best Dialog on Earth

If you’ve put a “Crash” button in your dialog, you’ve failed. Then again, it does make application crashes more like a little minigame… Do I give up and burn it all or do I try to continue and see what this apocalyptic world looks like? (Spoiler: Every time I’ve ever hit “Continue” the app has crashed moments later.)

I showed this to a hacker-happy friend of mine, who gave me a lengthy comment on it.

Well, not really. If an assertion fails, it may be due to a memory corruption bug that incidentally overwrote some internal variable with a bogus value, “crashing” (e.g probably calling the abort() function) and thus producing a core-dump that may be inspected with a debugger is actually quite sane behavior in that case. Normally abort() would be called immediately upon a failed assertion, the only difference in this case is giving the option to continue anyway to be able to (possibly) save your work. I’d use “save as” in case the save gets corrupted / incomplete though.

Fortunately there’s a way to “beat the game” though. Just attach to the process with gdb and use the generate-core-file command, or the gcore utility. With enough assembly & reverse-engineering skills you could probably even parse out the relevant data structures in the memory dump and be able to restore any unsaved changes to your project from that. ;)

‎(If it wasn’t obvious from context, I might add that this should be done while the popup is showing and before pressing continue, in case the application crashes.)

Notes

  1. pestbarn reblogged this from maniacalrage and added:
    to a hacker-happy friend of mine, who gave me a lengthy comment on it.
  2. tkjohansson reblogged this from maniacalrage
  3. carpeaqua said: This is why I don’t run beta tools on my Mac anymore. No clue why Interface Builder fucks up so hard having two versions on it. Delete your IB preference and it fixes the issue though.
  4. thememorious reblogged this from maniacalrage
  5. deepthinking reblogged this from maniacalrage
  6. supersense reblogged this from osxchat
  7. intothelifeofme reblogged this from maniacalrage
  8. osxchat reblogged this from maniacalrage and added:
    resulting .xib may surprise you later in the most unwanted ways imaginable.
  9. maniacalrage posted this