Various problems & fixes

[Damian Ivereigh]

Hi Jeremy,

Welcome back from your hols...

Jeremy Allison wrote:
> Ok - I'll take a look at this.
> 
> > I have found another problem in the lib/select.c in the function
> > sys_select(). There seems to be this whole thing around avoiding race
> > conditions using a pipe. Anyway it doesn't seem to quite work. If for
> > some reason an extra character appears
> > in the pipe (that is not represented by the difference between
> > pipe_read & pipe_written), then the process is sent into an endless
> > loop (because it never tries to read this character). While this
> > shouldn't ever happen it does on our machines (about once a day under
> > heavy load)!
> 
> Hmmmm. This should never happen. I'd be *really* interested in helping you
> track this down. What OS are you running on ? Can you get the smbd to abort()
> on detection of this condition. This is a *critical* section of code and
> we must get this right.

Sure I can take my patch code back out and just make it abort()
instead. I should be able to
get that to you in the next few days. We are running Intel X86's with
a linux system loosely
based on RedHat 5.2 (i.e. we use the RH RPM's), so glibc etc are what
you would find on RH5.2

> > Another area which I wouldn't mind you looking at is the all the stuff
> > around the get_ntforms(), write_ntforms() & delete_a_form() - all in
> > printing/nt_printing.c. After a form is deleted a "hole" is left in
> > the tdb file (the index number is also stored). Next time
> > get_ntforms() is called an uninitialised section of memory is used in
> > the form list. When this is then written out again (write_ntforms()),
> > that garbage will be written to the tdb file. This may be enough to
> > really confuse the clients.
> 
> I'll take a look at this.

Thanks. Actually as I said in a later email. There is a lot of
optimisation that could be done here. The code looks like it was
designed to read/write a flat file and then it got converted to using
tdb. I don't believe the whole index number thing is even necessary
(but the code comments seem to disagree). It sure is nice for Letter &
A4 to appear at the top for asthetic reasons (since the first entry
often ends up being the default in the GUI selection window), but
apart from that I don't believe the order really matters. It certainly
doesn't seem necessary to load the whole list into memory for every
seperate change. I am quite willing to take on this task.

> Thanks for all the debugging help !

Hey you're very welcome! You can expect lots more since (believe it or
not) this going is going into production right now (with 6000
printers)!

On another aspect, I have backended much of the tdb records that used
to be in ntdrivers.tdb in our directory service. To do this I have had
to put minor changes in various places including
rpc_server/srv_spoolss_nt.c & printing/nt_printing.c (the former
mainly for performance). Anyway I am wondering if a little re-org that
would seperate the processing from the data storage, such that the
latter could be easily plugged in-and-out. Do you have any thoughts on
that? Again I am willing to take that on.

Damian

-- 
Damian Ivereigh
CEPS Team Lead
http://wwwin-print.cisco.com
Desk: +61 2 8446 6344
Mob: +61 418 217 582