Created attachment 522111 [details] Backtrace at the crash point I'm investigating an intermittent crash which happens when requesting to print a page in SeaMonkey, and it appears that the problem is a null pointer dereference in libcups.so. The machine is an AMD X2 running Fedora 14 x86_64 with the Linux-x86 download of SeaMonkey 2.3.2 and cups-libs-1.4.6-1.fc14.i686. The crash is fairly reproducible; it seems to be along the lines of: visit a page, print it (works fine), close that tab, continue browsing for several minutes, then find another web page to print, select File->Print and it will segfault. The backtrace at the point of the segfault (attached) indicates that it died while executing cups_compare_dests() with a null second argument, called from cups_find_dest with dests=NULL, called from the section of cups_get_sdests(op=CUPS_GET_CLASSES) which is headed "If we sent a CUPS_GET_CLASSES request, check whether CUPS_GET_PRINTERS already gave us this destination and exit early if so." The problem seems to have been that CUPS_GET_PRINTERS returned no results, but I haven't found out why that is. In principle I suppose it is legitimate for that call to return no printers, if you are talking to an old-style cups server which has only classes and doesn't share the individual printers; I guess that the IPP request also return NULL if there was an HTTP error, which is more likely to be the case here. If that happens, then cups_get_sdests skips to the end section which says "If this is a CUPS_GET_PRINTERS request but we didn't see any classes we might be talking to an older CUPS server that requires CUPS_GET_CLASSES as well" and calls itself to get those classes. Then, when it receives the first class name it will look that name up in the list of zero printers found so far, and that's what causes the crash. Therefore, suggest checking that num_dests>0 before calling cups_find_dest to check the printer name against the list of names already found.
Could you try cups-1.4.8 from updates-testing (it's actually populating stable repo at the moment) to make sure the problem still persists in the latest release ? yum --enablerepo=updates-testing update 'cups*'
Yes, still reproduceable with cups-libs-1.4.8-2.fc14.i686. A bit more info on the crash. It seems to be to do with the TCP connection to the server closing down (it may therefore be relevant that I'm using a remote cups server, specified in /etc/cups/client.conf - there is no cups daemon running locally). So, to reproduce the crash, bring up File->Print and then close it (it's not necessary to go through with the print). This leaves a TCP connection open to the server. Then watch "netstat --inet" periodically and eventually the connection will close down. At this point, if you do File->Print again, it will crash. So I believe the first CUPS_GET_PRINTERS mentioned above is receiving an EPIPE because the connection has closed down, so returns an error, which leads to CUPS_GET_CLASSES (presumably now using a new connection) and thence to the crash.
Thanks, should be fixed now.