Peter Lees wrote:
> folks - this shouldn't be hard...
>
> lpstat is dumping core on me (segfault):
>
> # lpstat -t
> scheduler is not running
> system default printer: lp
> system for sydsoc_ricoh: ricoh-printer (as
> lpd://ricoh-printer/printers/lp#Solaris)
> sydsoc_ricoh not accepting requests since 19 February 2007 3:21:13 PM
> unknown reason
> Segmentation Fault(coredump)
>
> * * *
> here's the last bit of a truss on that command:
>
> 2128: read(7, " ", 1) = 1
> 2128: read(7, " I", 1) = 1
> 2128: read(7, " d", 1) = 1
> 2128: read(7, " l", 1) = 1
> 2128: read(7, " e", 1) = 1
> 2128: read(7, " .", 1) = 1
> 2128: read(7, " (", 1) = 1
> 2128: read(7, " R", 1) = 1
> 2128: read(7, " e", 1) = 1
> 2128: read(7, " a", 1) = 1
> 2128: read(7, " d", 1) = 1
> 2128: read(7, " y", 1) = 1
> 2128: read(7, " .", 1) = 1
> 2128: read(7, " )", 1) = 1
> 2128: read(7, "\n", 1) = 1
> 2128: read(7, " O", 1) = 1
> 2128: read(7, " n", 1) = 1
> 2128: read(7, " l", 1) = 1
> 2128: read(7, " i", 1) = 1
> 2128: read(7, " n", 1) = 1
> 2128: read(7, " e", 1) = 1
> 2128: read(7, " /", 1) = 1
> 2128: read(7, " O", 1) = 1
> 2128: read(7, " f", 1) = 1
> 2128: read(7, " f", 1) = 1
> 2128: read(7, " l", 1) = 1
> 2128: read(7, " i", 1) = 1
> 2128: read(7, " n", 1) = 1
> 2128: read(7, " e", 1) = 1
> 2128: read(7, " ", 1) = 1
> 2128: read(7, " :", 1) = 1
> 2128: read(7, " ", 1) = 1
> 2128: read(7, " O", 1) = 1
> 2128: read(7, " n", 1) = 1
> 2128: read(7, " l", 1) = 1
> 2128: read(7, " i", 1) = 1
> 2128: read(7, " n", 1) = 1
> 2128: read(7, " e", 1) = 1
> 2128: read(7, " .", 1) = 1
> 2128: read(7, "\n", 1) = 1
> 2128: read(7, "\n", 1) = 1
> 2128: Incurred fault #6, FLTBOUNDS %pc = 0xD26E109B
> 2128: siginfo: SIGSEGV SEGV_MAPERR addr=0x00000000
> 2128: Received signal #11, SIGSEGV [default]
> 2128: siginfo: SIGSEGV SEGV_MAPERR addr=0x00000000
>
>
> i don't care whether the printer is sending back weird info, it's
> unacceptable that
> lpstat segfaults
I would totally agree with you there - but no matter how much defensive
programming is built into software it can never be 100% bug free, so I
guess you have fallen down one of those holes :-( . And I expect the
solaris print development team would apologize for that.
They might want you to get the trace from the 'core' file (and do 'file
core') to help them track down the root-cause of the problem (using a
debugger on the 'core' file).
>
> thank god openoffice has a relatively independent printing subsystem so i can
> still print documents despite this debacle
>
> Solaris Nevada snv_55b X86 on laptop
> ricoh aficio 2238C printer
>
> if this can't be made right and *simple* we can forget about solaris as a
> productivity platform
>
