Re: [Lprng-devel] Welcome to lprng

[Tim M. <Tim...@nd...>]

In regard to: Welcome to lprng, walter harms said (at 3:00pm on Nov 1, 2013):

> Hello Tim Mooney,

Hi Walter & lprng-devel!

I'm new to the list, but not LPRng.  The university where I work has
been using LPRng since the mid 1990s.  We used its predecessor, PLP,
before that.  You'll find my name scattered throughout the CHANGES
document for various patches, especially to the documentation, and
suggestions over the years.

I went looking for a fork of LPRng a few years ago, after it was clear
that Patrick Powell was no longer doing maintenance on it.  I found your
lprng SourceForge project at that time, but almost no changes had been
made to the source to that point, so I didn't follow the project closely.

I found the project again because I was looking to see if anyone that
was still using it was experiencing the kinds of issues that we do,
specifically segfaults that appear to be memory corruption.

We're using Patrick Powell's 3.8.33 (I see that he released a 3.8.35,
but the changes are tiny), and had the same issues under 3.8.24 before
that.

We use LPRng with GoPrint, a commercial print management and cost-recovery 
system primarily targeted at universities and libraries.  All queues are
set up with LPRng as hold queues.  Users interact with GoPrint at
touch-screen kiosks near the printers, using their campus ID card to check
their printing balance against our ID system and select and release print
jobs they've submitted.  It's GoPrint that decides whether they should
be able to actually print the job, and it's that software that ultimately
issues the "lpc move" and "lpc release" commands to LPRng, to get the
selected print jobs to release to the printer.  The system receives
anywhere from a few hundred to more than 8,000 print jobs per day, and
page totals printed per day range from 5,000 to more than 35,000.

The system itself is quite slick, but unfortunately LPRng has been the
weak link.  Our system logs and dmesg output on the RHEL 5.10 print
server that hosts GoPrint and LPRng are filled with segfaults from lpd
workers:

$ dmesg | egrep 'lpd.*segfault' | wc -l
1498

I've just recently spent some time on it, and have been able to identify
a common stack trace:

Program terminated with signal 11, Segmentation fault.
#0  0x0078905e in malloc_consolidate () from /lib/libc.so.6
(gdb) where
#0  0x0078905e in malloc_consolidate () from /lib/libc.so.6
#1  0x0078b2e7 in _int_malloc () from /lib/libc.so.6
#2  0x0078d27a in calloc () from /lib/libc.so.6
#3  0x0070c80b in _dl_new_object () from /lib/ld-linux.so.2
#4  0x00708011 in _dl_map_object_from_fd () from /lib/ld-linux.so.2
#5  0x00709f71 in _dl_map_object () from /lib/ld-linux.so.2
#6  0x00713d41 in dl_open_worker () from /lib/ld-linux.so.2
#7  0x007100d6 in _dl_catch_error () from /lib/ld-linux.so.2
#8  0x00713742 in _dl_open () from /lib/ld-linux.so.2
#9  0x0082cbf2 in do_dlopen () from /lib/libc.so.6
#10 0x007100d6 in _dl_catch_error () from /lib/ld-linux.so.2
#11 0x0082cda5 in __libc_dlopen_mode () from /lib/libc.so.6
#12 0x008099b9 in init () from /lib/libc.so.6
#13 0x00809b53 in backtrace () from /lib/libc.so.6
#14 0x007829b1 in __libc_message () from /lib/libc.so.6
#15 0x0078ad35 in _int_free () from /lib/libc.so.6
#16 0x0078eda9 in free () from /lib/libc.so.6
#17 0x0805b0a3 in Set_str_value (l=0xffbb5120, key=0x80b214e "user",
     value=0x823aff2 "er=er=er.er.er.en.ensens8ns83s83")
     at ./common/linelist.c:1053
#18 0x0807cc7f in Perm_check_to_list (list=0xffbb5120, check=0x80bac00)
     at ./common/permission.c:704
#19 0x08092dd6 in Do_queue_control (user=0x823bbe0 "goprint", action=20,
     sock=0xffbb5340, tokens=0xffbb5230, error=0xffbb517c "", errorlen=180)
     at ./common/lpd_control.c:448
#20 0x08093b43 in Job_control (sock=0xffbb5340, input=<value optimized
out>)
     at ./common/lpd_control.c:184
#21 0x0806435e in Service_lpd (talk=5, from_addr=0xffbb537c "127.0.0.1
port 0")
     at ./common/lpd_dispatch.c:341
#22 0x0806482c in Service_connection (args=0xffbb54b4)
     at ./common/lpd_dispatch.c:310
#23 0x080575a6 in Do_work (name=0x80a60d2 "server", args=0xffbb54b4)
     at ./common/linelist.c:3853
#24 0x080587d8 in Make_lpd_call (name=0x80a60d2 "server",
passfd=0xffbb54c0,
     args=0xffbb54b4) at ./common/linelist.c:3823
#25 0x0805cd8c in Start_worker (name=0x80a60d2 "server", parms=0xffbb54fc,
     fd=12) at ./common/linelist.c:3882
#26 0x0804a989 in Accept_connection (sock=7, lpd_socket=0, unix_socket=1)
     at ./common/lpd.c:1015
#27 0x0804bf61 in main (argc=Cannot access memory at address 0x0
) at ./common/lpd.c:693


The segfault is triggered by the call to free() in Set_str_value (frame
#16 and #17), and it's "value" that's corrupt, but I haven't yet had time
to track down where the initial corruption is happening.

I see that since I first looked at your lprng fork, you have made
significant changes, dropping a lot of the cruft that had accumulated
over the years.  That seems like a good direction to take.

I'll review the your changes document, but how compatible is lprng with
the older LPRng, from a config file and accepted options perspective?  Is
it essentially a drop-in replacement for LPRng, or has there been enough
divergence that some things now work differently or e.g. the control
file format is now different?

Thanks,

Tim
-- 
Tim Mooney                                             Tim...@nd...
Enterprise Computing & Infrastructure                  701-231-1076 (Voice)
Room 242-J6, IACC Building                             701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164