Bug 244530 - print/cups-pdf backend segmentation fault upon upgrade to revision r527186
Summary: print/cups-pdf backend segmentation fault upon upgrade to revision r527186
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-03-01 00:44 UTC by russo
Modified: 2021-04-13 16:35 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description russo 2020-03-01 00:44:43 UTC
After updating ports to revision r527186, cups-pdf stopped working on my system. Enabling debugging output from cups, I see:

    D [29/Feb/2020:17:14:18 -0700] [Job 1613] PID 66844 (/usr/local/libexec/cups/backend/cups-pdf) crashed on signal 11.

in the error_log.  This happens when trying any printing to the cups-pdf device, be it a test page through the cups web interface or just trying to send any file to the virtual printer.

Reverting to revision r506647 (svn update -r506647 in the /usr/ports/print/cups-pdf directory and reinstalling the port) and restarting the cupsd service restores print to pdf capability.  I can "print" anything to PDF so long as I don't update to revision r527186.  For the moment, that's an acceptable solution.  It would still be nice to get past it.

I am unable to get any core file or anything from the cups-pdf run, and don't know how to invoke it in any meaningful way to make it do something other than print its help (which does NOT segfault).  Other than the notification that the backend crashed in the printer status page of the cups web interface, and the single line reporting it died with signal 11 in the error_log, there is no information I can find to diagnose what's wrong here.

My uname:
FreeBSD xxxx.xxx 11.3-STABLE FreeBSD 11.3-STABLE #1 r354399: Wed Nov  6 11:58:48 MST 2019     xxxx@xxxx.xxx:/usr/obj/usr/src/sys/GENERIC  amd64

I have built cups-pdf with the HOME_SUBDIR variable set to "PrintToPDF," so printing to PDF deposits the PDF in a subdirectory of the user's home directory called "PrintToPDF".

The relevant chunk of /usr/local/etc/cups/printers.conf:

    <Printer Virtual_PDF_Printer>
    UUID urn:uuid:ef6198c4-1832-36b4-6420-be36d560509a
    Info Virtual PDF Printer
    Location The Virtual World
    MakeModel Generic CUPS-PDF Printer
    DeviceURI cups-pdf:/
    State Idle
    StateTime 1583022141
    ConfigTime 1457822941
    Type 8450124
    Accepting Yes
    Shared Yes
    JobSheets none none
    QuotaPeriod 0
    PageLimit 0
    KLimit 0
    OpPolicy default
    ErrorPolicy stop-printer
    </Printer>

The PPD file I have installed in /usr/local/etc/cups/ppd for this printer has no diffs to the one that is installed by the port (/usr/local/share/cups/mode/CUPS-PDF.ppd) except that the on installed by the port has "A4" paper size and mine has "Letter" on exactly four lines.

I can do other experimenting and reporting of information as needed.
Comment 1 James B. Byrne 2020-05-27 18:28:39 UTC
Possibly related.  I am unable to obtain output from cups-pdf through the mate desktop.  The pdf file is created but it is left in `/var/spool/cups/` rather than `/var/spool/cups-pdf/username/` and has a name in form `d01676-001`.

If I open the cups webpage then cups-pdf shows this:
`
cups-pdf-1672  	Unknown  	Withheld  	168k  	17  	pending since
Fri May 15 11:03:09 2020 
"Backend failed" 	
 
cups-pdf-1676  	Unknown  	Withheld  	58k  	Unknown  	pending since
Wed May 27 10:58:52 2020 ` 	
 

This behaviour began after January 20, 2020.
Comment 2 James B. Byrne 2020-05-27 19:26:33 UTC
And cups-pdf was installed through pkg.
Comment 3 James B. Byrne 2020-05-27 19:46:33 UTC
This is what is in /var/cache/pkg relating to cups-pdf:

find /var/cache/pkg -type f -name \*cups\* -exec ls -D '%F' -l {} \; | sort -k6 | grep cups-pdf
-rw-r--r--  1 root  wheel  23376 2018-10-25 /var/cache/pkg/cups-pdf-2.6.1_4-4e9e1e3d16.txz
-rw-r--r--  1 root  wheel  23836 2019-03-30 /var/cache/pkg/cups-pdf-2.6.1_4-23dc9778df.txz
-rw-r--r--  1 root  wheel  26360 2020-03-17 /var/cache/pkg/cups-pdf-3.0.1-40d4d99245.txz
-rw-r--r--  1 root  wheel  26376 2020-05-24 /var/cache/pkg/cups-pdf-3.0.1-152f428636.txz

The update to cups-pdf-3.0.1 on 2020-03-17 seems to be when the problem started.
Comment 4 James B. Byrne 2020-05-27 19:56:37 UTC
And, finally, when printing from mate to the cups-pdf printer the progress window reports that the backend had a segmentation fault but I cannot find this recorded in the logs.
Comment 5 taras.filatov 2020-06-07 13:57:06 UTC
about cups-pdf version 3.0.0
cups-pdf crashes at code
 group=getgrnam(Conf_Grp);
    grpstat=setgid(group->gr_gid);
while setting new gid for own process. Conf_Grp is NULL.

this is because conf file assumed /etc/cups/cups-pdf.conf and cannot be opened. And at this stage nothing can be logged (previous function read_config_file(filename); tries to do log_even, but log file still not open...)

And this is because of mistake in Makefile: in pdf-conf.h now contains
/* location of the configuration file */
#define CP_CONFIG_PATH "/usr/local/etc/cups"

but current Makefile tries to correct this:
post-configure:
        @${REINPLACE_CMD} ${_SUBST_CMD} ${WRKSRC}/extra/cups-pdf.conf
        @${REINPLACE_CMD} -e \
                's,CPCONFIG "/etc/cups/cups-pdf.conf",CPCONFIG "${ETCDIR}/cups-pdf.conf",' \
                ${WRKSRC}/src/cups-pdf.h

So solution:
1) Makefile should be corrected like this:
--- Makefile.orig	2020-06-07 15:42:18.182963000 +0300
+++ Makefile	2020-06-07 16:50:19.899876000 +0300
@@ -78,7 +78,7 @@
 post-configure:
 	@${REINPLACE_CMD} ${_SUBST_CMD} ${WRKSRC}/extra/cups-pdf.conf
 	@${REINPLACE_CMD} -e \
-		's,CPCONFIG "/etc/cups/cups-pdf.conf",CPCONFIG "${ETCDIR}/cups-pdf.conf",' \
+		's,\#define CP_CONFIG_PATH "/etc/cups",\#define CP_CONFIG_PATH "${ETCDIR}",' \
 		${WRKSRC}/src/cups-pdf.h
 
 do-build:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~`

2) if your ever edit cups-pdf.conf and set Grp to nonexistent group, e.g. lp, cups-pdf will crash silently. So I propose add some code to tell about it to stderr:
--- src/cups-pdf.c.orig 2017-02-24 18:32:46.767977798 +0200
+++ src/cups-pdf.c      2020-06-07 16:18:14.701263000 +0300
@@ -374,7 +374,13 @@
   (void) umask(0077);
 
   group=getgrnam(Conf_Grp);
+  if (group != NULL)
     grpstat=setgid(group->gr_gid);
+  else {
+         fprintf(stderr,"Get group data (getgrnam) failed! group name was %s\n",Conf_Grp);
+         fprintf(stderr,"GID of process not changed!\n");
+         return 1;
+  }
 
   if (strlen(Conf_Log)) {
     if (stat(Conf_Log, &fstatus) || !S_ISDIR(fstatus.st_mode)) {
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
put this in file like patch-group_cups-pdf.c and put it inf folder files/ (create int port's folder).
Comment 6 taras.filatov 2020-06-07 14:00:05 UTC
(In reply to taras.filatov from comment #5)
Sorry, mistake -- it's about cups-pdf-3.0.1...
Comment 7 Tatsuki Makino 2021-04-13 06:17:23 UTC
Has this already been fixed by Bug 246955?
Comment 8 russo 2021-04-13 16:33:38 UTC
This does appear to have been fixed quite some time ago in git commit 709dd0f0 to the ports repo which applied a patch that basically did what was suggested in comment 5, but did not reference this issue in bugzilla.
Comment 9 russo 2021-04-13 16:35:22 UTC
And I should note that I've been using cups-pdf after the patch since around June of 2020, I should have closed the issue myself.