Re: Printing not working at all...

[Riccardo Mottola]

Hi,

Richard Frith-Macdonald wrote:
> > Richard, do you have a clue why we crash inside NSCountFrames() when allocating 
> > the exception??
> That's quite common; when the stack is corrupt (and possibly in some other 
> circumstances on older systems), the function to count the stack frames will 
> segmentation fault.
> The stack frame unwindiing code therefore wraps things in a signal handler to 
> catch attempts to walk off the end of the stack, and recover/continue.

but the stack shouldn't be corrupt if we are just using the wrong domain 
to retrieve the PPD file and the PPD file doesn't get found.

ppdString = [NSString stringWithContentsOfFile: ppdPath];

Is I suppose safe and tested against non-existing files.
Perhaps the corruption happened because we did something invalid much 
earlier?

We are here in the LPR backend, as we can see that GSLPRPrinter gets 
allocated.

And we see that the printer info is bogus:
(gdb) po printerEntry
{Host = localhost; Note = "Automatically Generated"; PPDPath = 
"/Local/Library/PostScript/PPD/English.lproj/Generic-PostScript_Printer-Postscript.ppd"; 
Type = Unknown; }

I found this in the defaults:

disc$ defaults read | grep rint
Ink GSLPRPrinters '{
        PPDPath = 
"/Local/Library/PostScript/PPD/English.lproj/Generic-PostScript_Printer-Postscript.ppd";
Vespucci GSLPRPrinters '{
        PPDPath = 
"/System/Library/PostScript/PPD/English.lproj/Generic-PostScript_Printer-Postscript.ppd";
Graphos GSLPRPrinters '{
        PPDPath = 
"/System/Library/PostScript/PPD/English.lproj/Generic-PostScript_Printer-Postscript.ppd";

the Ink entry is wrong, perhaps from an old installation which had a 
different domain? This explains also why e.g. Graphos was working fine.

I just issued
disc$ defaults delete Ink GSLPRPrinters


and I can print!

So.. no bug in the printing code (it also means I can't reproduce Greg's 
issue: on this NetBSD computer I can print and on Ubuntu I can print but 
have just an invalid font name, a minor issue, not a 0 bytes PS file).

I still find it a bit bad that in such a condition we can't warn the 
user and instead crash with a SIGSEV.



Riccardo