Getting random crashes when screen savers are running. Can someone help me figure out a log from MacsBug?

[bribri]

I have an SE/30 running System 7.1. When I'm not using it, it's usually displaying a random one of my favorite screensavers. (I have After Dark 2.0y installed.)

However, every now and then the system crashes, and I'm wondering if I can figure out why, and if the answer is anything more than "After Dark is unstable". I'd very much like to continue running After Dark if I can!

I've attached a log created by MacsBug, but I'm still new to it so I'm not sure when to gleam from it, other than something went wrong in the Finder (maybe) when it was trying to create a new PixPat. Was it even the Finder, or was it actually After Dark?

Here's the relevant stack trace:

 Disassembling from 4081F00C
  _OldPatToNew
     +00008 4081F00C   MOVEA.L    $0008(A6),A0                          
  | 206E 0008
     +0000C 4081F010   MOVE.L     (A0),D0                               
  | 2010
     +0000E 4081F012   BEQ.S      _OldPatToNew+00018         ; 4081F01C 
  | 6708
     +00010 4081F014   MOVEA.L    D0,A3                                 
  | 2640
     +00012 4081F016   MOVEA.L    (A3),A1                               
  | 2253
     +00014 4081F018  *TST.W      (A1)                                  
  | 4A51
     +00016 4081F01A   BEQ.S      _OldPatToNew+0003C         ; 4081F040 
  | 6724
     +00018 4081F01C   CLR.L      -(A7)                                 
  | 42A7
     +0001A 4081F01E   JSR        ([NewPixPat])                         
  | 4EB0 81E1 161C
     +00020 4081F024   MOVEA.L    $0008(A6),A0                          
  | 206E 0008
     +00024 4081F028   MOVE.L     (A7)+,(A0)                            
  | 209F
     +00026 4081F02A   MOVEA.L    (A0),A3                               
  | 2650
     +00028 4081F02C   MOVEA.L    (A3),A1                               
  | 2253

 

[Nycturne]

It's been a loooong time since I've done any 68K assembler, so take some of this with a grain of salt.

This function seems to be a private Toolbox function to convert pixel patterns? It gets passed in a pointer/handle(?) to a data structure of some kind. It pulls some data out of that structure as another pointer and calls TST.W on it. This fails, because the address is basically bonkers: 0x235E4EF9. This is somewhere around 595MB into the 32-bit address space. Too high to be a valid RAM address, too low to be a valid ROM address (which starts at 0x40800000).

So it looks like whatever data structure was passed into _OldPatToNew was overwritten, invalid, or simply uninitialized. Why? No idea from just the log. Someone would need to poke around a bit in the debugger to extract more information to get a better idea of what's going on.

That said, it's interesting that the addresses in use are related to Heap zone #9 and #10. #9 isn't marked, but #10 is Apple Events? Is it possible #9 is the After Dark heap? Not sure. But even more interesting is that it looks like we've got the original pointer that was passed in as a parameter in A0, which is in the AE heap, but dereferencing it gives us an address in heap #9. So is #9 the originator of the Apple Event perhaps, and the Finder is the target of it?

Honestly, in terms of trying to understand, you'd need to work back from this to an understanding of how you got here. I'd probably start by looking at the Inside Macintosh documentation around Pixel Patterns. What do these structures look like and are they valid? What is the actual call stack (what you provided was just disassembly of the instructions in _OldPatToNew)? Do you have anything else installed that manipulates graphics that might be in play? It looks like some Apple Event related to a pixel pattern is at fault, but it's not entirely clear why Apple Events are in play, or why someone would be passing pixel patterns via an Apple Event. I just am too rusty on pre-OS X architecture.

EDIT: It looks like "KQ Apple Events" is actually "KeyQuencer"? Are you using this for automating something? This makes me think that it's not necessarily After Dark, but KeyQuencer that is your issue, since its memory heap is implicated in the crash.

 

[bribri]

Yes, I do have KeyQuencer installed and I've used it for some automation. I'm going to try running the screen savers for several hours with KeyQuencer and some other extensions disabled to see if the crash still happens in that case. It typically happens within 24 hours, but given how intermittent it is, it'll be difficult to tell for sure if the crash is gone. I don't have any way to reproduce it consistently.

 

[Nycturne]

Yeah, these sort of intermittent crashes can be painful to track down. Crash dumps made this sort of thing so much easier once we had the ability.

Still, I wonder if you had anything setup to do something like set the desktop pattern? It seems like the most obvious reason the Finder would be involved with an Apple Event that has a PixPat involved.

 

[bribri]

I can't think of any reason why the Finder would be doing something involving creating patterns. It does have a desktop background, but I'd presume that's just stored in memory since the Finder redraws the desktop constantly. There's no reason for it to be processing an Apple event, or for KeyQuencer to be doing anything.

In any case, I disabled almost every single extra extension and control panel other than After Dark, and still got the same crash during a screen saver, so apparently it's not an incompatibility from another extension. It's probably just a bad bug in After Dark, but I'll keep digging into it.

Currently I'm keeping my Mac idling with After Dark disabled (and the screen turned off of course) to see if the crash still happens, just in case this is a more pervasive problem then unstable screen savers.

 

[Nycturne]

I can't think of any reason why the Finder would be doing something involving creating patterns. It does have a desktop background, but I'd presume that's just stored in memory since the Finder redraws the desktop constantly. There's no reason for it to be processing an Apple event, or for KeyQuencer to be doing anything.

In any case, I disabled almost every single extra extension and control panel other than After Dark, and still got the same crash during a screen saver, so apparently it's not an incompatibility from another extension. It's probably just a bad bug in After Dark, but I'll keep digging into it.

Currently I'm keeping my Mac idling with After Dark disabled (and the screen turned off of course) to see if the crash still happens, just in case this is a more pervasive problem then unstable screen savers.

Is it the same crash, I wonder? A lot of what I saw was based on the heaps the PixPat was associated with, as there wasn't much more to go on in the crash logs without a stack trace. MacsBug calls it a stack crawl, and has the 'sc' command for providing it. This would at least give us a better idea what code was actually executing.

Usually when I've had to diagnose this sort of intermittent issue, it's worth capturing fresh data when eliminating causes that the data points to. If this is something that leads to a more general issue with say, memory allocation issues which is likely in this case, then we'll see patterns emerge from the different crashes. Fresh crash data could very well be illuminating in your case.

EDIT: I did poke around a bit more at the QuickDraw side of things, and it doesn't really reveal anything terribly new. It looks like the crash shared in the original post was a case of a Basic QuickDraw PixPat being used to do drawing. However, when using these older pixel patterns to draw in a color-capable graphics port, it needs to convert the PixPat to a modern one. But none of that matters if the PixPat being used to do the drawing is invalid.

Re-checking the addresses though, it does look more and more like the classic case of either a disposed handle or a fake handle was passed into drawing routines. I also got the heap boundaries wrong, so my early analysis there was wrong. But this could very well be a bug somewhere in After Dark if that's the case.

 

[bribri]

I've got the screen savers running again, and I'll do that when I get another crash. In the meantime I can say that the system did not crash over the course of several days when idling, which makes it more likely this is a bug in After Dark.

 

[bribri]

Okay, I think I've got it sorted out. Naturally there were some screen saver modules I was using that were unstable.

The trick came from me digging through the archives of comp.sys.mac newsgroup looking for clues. I found several posts there from the After Dark devs emphatically making the case that After Dark is stable, and it is almost always bad modules that cause crashes. Further, they made it clear that lots of modules may be fine when used individually but don't work when used with their randomizer module, which is what I've been using. However they suggested setting the randomizer duration to very short, so that it flips through all of the modules super rapidly, and then trying to figure out which ones are causing crashes.

I'll give myself a pat on the back for my debugging skills, because with a combination of a binary search where I was turning modules on and off in groups, and using the information provided by MacsBug stdlog which revealed which module was running when a crash occurred, I was able to find the crash was happening because of an interaction between two modules! Once I removed them, that particular crash went away. Hopefully there aren't others waiting in the wings.

edit: The modules in question were: "Major Metaphysical Appliances" and "Saw". I found an unrelated crash caused by "ICON Crash!" as well.

Also, I think it pointed to Finder being the cause of the crash purely because it was the active app. But the real cause was the running After Dark modules.

 

[Nycturne]

Glad you got it sorted out.

Also, I think it pointed to Finder being the cause of the crash purely because it was the active app. But the real cause was the running After Dark modules.

This is expected behavior I think. After Dark is a system extension, so it doesn't have its own process. I'm not even sure the System has a process in System 7.