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