Icky Crash Report

[Tobias Peciva]

Hey,

Yep. To give a bit more detail, this is actually a custom CUPS  
backend. Basically, it's just a command line tool that obtains some  
information, tacks it onto the spool file being printed, then invokes  
the standard lpd backend to send the job to a remote server.

The backend uses Distributed Objects to talk to another application.  
As far as we can tell, the crash happens while the backend is waiting  
for a response from the (synchronous) DO call: Not when opening the  
connection or making the request, but after a second or two of  
waiting. From the perspective of the other application, it accepts  
the DO connection on a separate thread, receives the request and  
starts interacting with the user. But while the user interaction is  
happening on the main thread, the backend dies and the DO connection  
on the separate thread is (obviously) lost.

The customer reports that only a small percentage of jobs fail, so  
it's intermittent. We haven't been able to reproduce it on any platform.

Peace,
Tobias

On 29/03/2007, at 5:24 PM, Rob Keniger wrote:

>
> On 29/03/2007, at 14:46, Tobias Peciva wrote:
>
>> We've had the following crash report submitted by a customer. It's  
>> a bit light on useful information: None of the addresses appear to  
>> map to anything in our application, and as you can see, Crash  
>> Reporter failed to obtain translated code information. We sent the  
>> customer a build with debug symbols and got a new crash report  
>> back, but it was essentially identical.
>>
>> Rosetta crash? Any other suggestions?
>
> There's this line indicating the process that is crashing:
>
> 0xb8000000 - 0xb82d9fff popup             /usr/libexec/cups/backend/ 
> popup
>
> CUPS is used by the Mac OS X printing system, is the crash  
> occurring when printing? Perhaps the customer has a custom CUPS  
> plugin installed which is crashing?
>
> --
> Rob Keniger