Version: 3.2.3 (using KDE 3.2.3, compiled sources) Compiler: gcc version 3.2 OS: SunOS (sun4u) release 5.9 Konqueror crashes when trying to print if selected print system is cups. This occurs on Solaris Sparc but not Linux x86. If alternatively I start konqueror from konsole then it does not crash and prints successfully. This problem occurs on both 3.2.2 with --enable-debug --disable-final and on 3.2.3 with --disable-debug --enable-final.
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.