Bug 86508

and the stacktrace is? 

Please, could you provide a backtrace (for example from the crash dialog that should appear). As it looks like you have a KDE compiled with debug enabled, please provide a backtrace using that version.

Created attachment 6999 [details]
Backtrace

Here is the backtrace from the 3.2.2 release, which I compiled with debug on

Also - the cups printers are remote ones. i.e. I have 'ServerName yrprnt' in
/etc/cups/client.conf

Just for the record, does it change anything if you use a local CUPS server? (it shouldn't, but you never know...).

The backtrace you provided shows the problem occurs in the CUPS library. Which version are you using? Is it possible for you to upgrade it? If you do, can you compile CUPS with debug enabled and provide another backtrace along with debug output on STDOUT?

I guess the print manager doesn't work neither: "kcmshell printmgr".

Michael
	It's cups 1.1.19 on both remote server and the local libs kde is linked against. I'll try to compile 1.1.20 tommorrow. I won't be able to swap the version on the server but the local libs / kde recompile should be possible.

Or would you rather me try the 1.1.21 release candidate?

Best Regards

Andrew

Michael
1/ Tried local cups spooler - exactly the same effect.
2/ Tried kcmshell printmgr - works just fine.

Thought I ought to mention that the same print dialog that crashes under konqueror, is OK when called from kmail.

I'll try out the rebuild with cups debug enabled first just by compiling cups and dropping in the new libcups.so. because it's a major event to build kde on sparc.

Andrew 

Created attachment 7017 [details]
Backtrace with cups --enable-debug

Michael
	Here is the backtrace with cups debug enabled. Note this is 1.1.21rc1
with debug. I have just replaced the libcups.so.2 in my /usr/lib with this
version, not compiled kde against it.

Thanks

Andrew

Huh, it's getting weird...
1) the crash doesn't occur at the same place as in your first backtrace
2) it only happens in konqueror, but from the KDEPrint's point of view, it doesn't matter from which application it is used, the behavior is the same

Is it possible for you to add the line: "req.dump(2);" just after the line "IppRequest req;" in kdelibs/kdeprint/cups/kmcupsmanager.cpp" around line 913, then simply doing a "make && su -c 'make install'" in kdelibs/kdeprint/cups/ to only recompile that little part.

As you compiled cups with debug enabled, there should be some additional message on the standard output when an app is started in a terminal (additional debug output should also result from the little change mentioned above). Could you provide the debug output when konqueror is started in a terminal?

Created attachment 7020 [details]
first log - with additional debug - CUPS_SERVER not set

This log with the additional logging. Does something surprising (to me). It
contacts the local cups server even though 'Server yrprnt' is specified in
/etc/cups/client.conf

Created attachment 7021 [details]
additional logging with CUPS_SERVER=yrprnt

This shows that kde will follow the CUPS_SERVER variable. Note - both this and
konq.log didn't crash since they were both run from a terminal.

KDEPrint uses the server mentioned in its config file ~/.kde/share/config/kdeprintrc, and can be changed from the KDEPrint settings dialog ("System Options" button in the print dialog, "CUPS" tab; or "kaddprinterwizard --kdeconfig"). On first startup, this is initialized to the same host as CUPS config itself (client.conf or CUPS_SERVER). I should probably fix this.
Now, do you mean that you don't have the problem when konqueror is started from a terminal? And you do when konqueror is started by another mean (for example "Start" menu)?

Michael
	I just changed the client.conf file and expected konqueror to switch without a full kde restart. Anyway this only really was odd behaviour I noticed. It did not contribute to the original problem.

	Yes the basic problem is that when konqueror is started from start menu or kicker it crashes, but when started from terminal it doesn't.

	I'm now just doing a complete rebuild of qt/kde etc just to be sure it's not a qt issue, since both versions of kde 3.2.[23] were built on the same compiled copy of QT.

Andrew

Best Regards


Andrew

Created attachment 7077 [details]
New Backtrace

Michael
	I've recompiled it and QT completely but the problem still occurs. I
had thought that the compiler(built on solaris 8) might have been the problem,
since the fault appears to be occuring in a threaded area.
	I notice that the backtrace shows _cupsRestoreLocale being called with
rubbish for arguments. Is cups thread safe do you know?

Regards

Andrew

Michael
	The problem still persists. I think it's something to do with stdin. As the following happens

1/ Start from 'menu|run command' with command 'konqueror' hit print button, konqueror crashes as before.

2/ Start from 'menu|run command' with command 'konqueror < /dev/null' hit print button, konqueror works properly.

I don't know if CUPS is thread safe (I think it is, refer to CUPS doc about that), but the fact that _cupsRestoreLocale is called with weird oldlocale argument might be normal. Indeed, looking at CUPS code, this argument has been previously generated by a call to "setlocale", and if I refer to "man setlocale" under Linux, it says that the returned value is an opaque string, so I don't think it is human-readable. If you have the time, you can try to compile the language.c file in "cups/" subdir of CUPS source with DEBUG defined to turn on some CUPS-specific debug messages (add -DDEBUG in the compile command).

UNCONFIRMED (batch reassigning messed this)

timeout for this bug.

Reporter didn't respond to Michael's suggestion since more than 2 years.... Other Solaris/KDE users have not complained. And we have KDE 3.5.5 now...

Closing old Resolved status bug.