[comp.windows.x] Xdbx 2.1

cheung@titan.sw.mcc.com (Po Cheung) (07/30/90)

A patched version of xdbx 2.1 (patch level 1) is now available on
expo.lcs.mit.edu as xdbx2.1.tar.Z under the contrib directory :

-rw-rw-rw-  1 ftp        114193 Jul 29 19:04 xdbx2.1.tar.Z

I simply overwrote the existing file with the patched version.
If you have ftp'ed before Sunday July 29, 7pm EDT, you may want
to ftp again.

Thanks,

Po Cheung
cheung@sw.mcc.com

lindholm@greve.ucs.ubc.ca (George Lindholm) (07/30/90)

In article <4028@titan.sw.mcc.com>, cheung@titan.sw.mcc.com (Po Cheung) writes:
|> A patched version of xdbx 2.1 (patch level 1) is now available on
|> expo.lcs.mit.edu as xdbx2.1.tar.Z under the contrib directory :

I brought it over (twice) and got
	"tar: directory checksum error (2905 != 36893)"

lindholm@staff.ucs.ubc.ca  George_Lindholm@mtsg.ubc.ca   USERGNL@UBCMTSG.BITNET
University of British Columbia Computing Services
(604) 228-4375

pfuetz@viktoria.grz (Matthias Pfuetzner) (08/30/90)

Hallo!

Yesterday   I compiled   and    installed   xdbx 2.1    as   posted in
comp.sources.x. I have  been doing this  on our VAXen  running  Ultrix
3.1. It compiled out of the box (using Gnu  C 1.35). The problem I now
have is the following:

Starting xdbx produces the following:

(Sitting at an Tektronix X-Terminal XN5  with  the release 3 server in
it)  xdbx opens its window and  immediatly closes it  again, finishing
its work this way.  (Sitting at a BULL DPX1000 also  with an MIT X11R3
server)   Fatal server bug: Cannot perform   Xalloc (this leading to a
complete hangup of the  xserver Xdpx  and furthermore producing a core
dump (I haven't analyzed it yet!)

Xdbx itself  was run on the VAXen  under Ultrix 3.1  and the MIT X11R4
things completly installed (all patches!).

Is there  anybody out  there  having the  same  problems or having any
hints where the problem wight be (and how it can be patched)?

Sincerly thankful for any answer,
	Matthias
            @work:            | Matthias Pfuetzner  |         @home:
  ZGDV, Wilhelminenstrasse 7  | 6100 Darmstadt, FRG |  Lichtenbergstrasse 73
    +49 6151 155-164 or -101  \    <- Tel.nr. ->    /     +49 6151 75717
   pfuetzner@agd.fhg.de    pfuetzner@zgdvda.UUCP    XBR1YD3U@DDATHD21.BITNET

rcomr@koel.co.rmit.oz (Mark Rawling) (08/31/90)

pfuetz@viktoria.grz (Matthias Pfuetzner) writes:


>Starting xdbx produces the following:
>....
>it)  xdbx opens its window and  immediatly closes it  again, finishing
>its work this way.  (Sitting at a BULL DPX1000 also  with an MIT X11R3
>server)   Fatal server bug: Cannot perform   Xalloc (this leading to a
>complete hangup of the  xserver Xdpx  and furthermore producing a core
>dump (I haven't analyzed it yet!)

>Is there  anybody out  there  having the  same  problems or having any
>hints where the problem wight be (and how it can be patched)?

This sounds like it is related to the xdbx bug whereby it suddenly goes
into limbo, chewing up memory, swapping out processes, and generally 
killing your machine until it eventually closes its window and dies 
with an error something like 'XtMalloc: cannot perform malloc'.

Cause and Fix:-

There are bugs in the regular expression code used by xdbx (regex.c).
Re's of the form \(....\)?, \(....\)+ and \(....\)* are dangerous since
(on my machines at least (sun3 and 4)) any reference to a register which
has a ?+* on it leads to bogus end addresses for the corresponding register.
eg the pattern 'aaaaaxxxxxxaaaaa' matched against .*\(x\)*.* should match
and register 1 should start at 5 and end at 10. Instead, it will start at 
5 and more than likely end at -2876436460346! xdbx tries to malloc an
area as big as `end-start'. The bug is in the reg ex compiler which plants
an incorrect 'on failure jump' address for these patterns. There is however
an easy work around - simply don't reference registers with repeats,
eg in the above example use .*\(\(x\)*\).*, now reg2 is the bogus one
but we only want reg1 to get the xxxxx pattern.

Thus I use the following pattern for output_pattern[0] (in sun_regex.h)

{"\\(.*\n\\)*.*\
\\(\\(stopped\\|Bus error\\|Segmentation fault\\|interrupt\\|signal.*\\|\
Unexpected SIG[^ ]+\\)\
in \\([^ ]+\\) at \\(line \\)?\\([0-9xa-f]+\\)\
\\( in file \"\\([^\"]+\\)\"\\)?\\)\n\
\\(Current function is [^ ]+.*\n\\)?\
\\(.*\n\\)?\
\\(\\(.*\n\\)*\\)",
NULL,
{2, -1, 4, 6, 8, 11}
},

NB: you have to set RE_NREGS to say 15 (ie >=11) in regex.h.
(I also changed the max failure stack to 100000 from 20k but am working on
a fix which means that xdbx does not match these complex patterns against the
entire output string which means the fail stack can be very small.)

I have not had a single malloc failure since making these changes.


-> Mark


============================================================================
Mark Rawling,	CSIRO High Performance Computation Group
		c/o Royal Melbourne Institute of Technology,
		email: rcomr@koel.co.rmit.oz{.au} phone: (+ 61 3) 660 2726