March 1999 - XEmacs-Beta - XEmacs Mailing List Archives

RE: Argh! What am I missing with MULE build? (21.0-b64 + Solaris 2.5 .1 + EGCS 1.1.1) 25 years, 8 months

Damon Lipparelli

Line 3186 is correct; sorry for the confusion. I am running whatever is in CVS as of 2:45 pm (PST) on 3/10. Also, you're right about pobj not understanding lrecords. In addition, without --gung-ho, marking a lrecord increments the pointer to the implementation held in the lrecord. Now onto today's debugging: I updated this morning, and re-built with debugging, no optimization, and without --gung-ho. See the attached stack trace for reference (this is from running "xemacs -q" under GDB). It looks like marking *(staticvec[1]) is where the crash is occuring (frame 5). This object is a Lisp_Vector with 16411 elements in it. Position 2753 is the symbol text-mode-symbol-table. All of the ASCII characters have been marked. Marking the 1th (that is, second) element of ct->level1[] is where the crash is occuring; "pobj" says: (struct Lisp_String *) 0x490400 {_size = 0, _data = 0x4e5000 "", plist = 3660} But, we end up in the Lisp_Type_Record section of mark_object() and crash. -lipp ps: Please note, configure'ing with --gung-ho fixes this problem. -----Original Message----- From: Gunnar Evermann [mailto:ge204＠eng.cam.ac.uk] Sent: Tuesday, March 09, 1999 4:54 PM To: XEmacs Developers Subject: Re: Argh! What am I missing with MULE build? (21.0-b64 + Solaris 2.5 .1 + EGCS 1.1.1) Damon Lipparelli <lipp(a)primus.com> writes: > It looks like the badness occurs the first time mark_object() is called. > We're are trying to mark the object pointed to by staticvec[0] (a hash > table). Stepping over line 2186 in "alloc.c" corrupts *(staticvec[0]). I assume you mean line 3186? Which version of alloc.c are you using anyway? The line numbers in your backtrace look like the latest one from CVS, i.e. including Martin's patch after 21.0-b65? I am afraid I just realized that the gdb commands cannot currently handle marked lrecords properly (at least for !USE_INDEXED_LRECORD_IMPLEMENTATION), so if you mean by 'corrupted' that pobj say 'unknown Lisp_Object' then that is expected :-( I noted below the following line numbers what kind of object is about to be marked at each point in your backtrace: > #0 0x4eb24 in mark_object (obj=541672448) at alloc.c:3183 > #1 0x6a5f0 in mark_char_table (obj=542035968, markobj=0x4e960 <mark_object>) > at chartab.c:145 > #2 0x4ec04 in mark_object (obj=542035968) at alloc.c:3193 Lisp_Type_Record marker function > #3 0x4ee64 in mark_object (obj=-1605681276) at alloc.c:3247 Lisp_Type_symbol sym->value > #4 0x4edb4 in mark_object (obj=-2143416320) at alloc.c:3229 Lisp_Type_Vector element i > #5 0x52090 in garbage_collect_1 () at alloc.c:4510 staticvec[i] If I read this right we're trying to mark a chartable which is the value of a symbol which is an element of a Vector which is staticpro'd. Could you check what this vector contains? possibly before the actual marking? Presumably it is already corrupted before the GC -- do you always get the crash on marking this particular vector? Then you might want to try the watchpoint or always_gc stuff Martin mentioned... FWIW I have an additional report of such a crash under 21.0b65... -- Gunnar Evermann Speech, Vision & Robotics Group Engineering Department Cambridge University

1 participants
0 comments

Re: XEmacs GIF bug? 25 years, 8 months

Gunnar Evermann

SL Baur <steve(a)xemacs.org> writes: > I get a ton of GIF errors referencing the URL: > http://www.sinica.edu.tw/ftms-bin/ftmsw3 > > (7) (error/warning) Error in process sentinel: (image-conversion-error First image in GIF file is not full size [gif :data GIF87a... > > > Hand loading the only GIF I see on that page does not yield the same > warnings. there are two GIFs -- the problem is the background one: http://www.sinica.edu.tw/~tdbproj/handy/upaper.gif glyphs-eimage.c contains: /* Note: We just use the first image in the file and ignore the rest. We check here that that image covers the full "screen" size. I don't know whether that's always the case. -dkindred(a)cs.cmu.edu */ if (unwind.giffile->SavedImages[0].ImageDesc.Height != height || unwind.giffile->SavedImages[0].ImageDesc.Width != width || unwind.giffile->SavedImages[0].ImageDesc.Left != 0 || unwind.giffile->SavedImages[0].ImageDesc.Top != 0) signal_image_error ("First image in GIF file is not full size", instantiator); for this image we get: (gdb) p unwind.giffile->SavedImages[0].ImageDesc $6 = {Left = 0, Top = 0, Width = 96, Height = 96, Interlace = 0, ColorMap = 0x0} (gdb) p *unwind.giffile $7 = {SWidth = 640, SHeight = 480, SColorResolution = 8, SBackGroundColor = 0, SColorMap = 0x8774160, ImageCount = 1, Image = {Left = 0, Top = 0, Width = 96, Height = 96, Interlace = 0, ColorMap = 0x0}, SavedImages = 0x87c52d8, Private = 0x87bee98, GifIO = 0x8793210} maybe we should just ignore the 'screen size' stuff and take the size from the first image? That seems to be what xv and netscape do, at least they have no problems and show a 96x96 image. BTW do we really want to dump all the binary junk in the warning buffer? In my first try I also got a funny core dump in the process, but I couldn't reproduce it later on and haven't checked more closely. Apparently the modeline contained illegal (in the MULE sense) junk and balloon-help-motion-hook (the function in frame#20 below) tried to map-extents over it... Running a MULE build is certainly more interesting than a normal version. :-) Gunnar Fatal error: assertion failed, file /local/srcdisk/gunnar/src/XEmacs/xemacs/src/insdel.c, line 364, VALID_CHARPTR_P (ptr) Fatal error (6). Lisp backtrace follows: map-extents(#<compiled-function (e ignored) "...(2)" [e] 1> Fatal error: assertion failed, file /local/srcdisk/gunnar/src/XEmacs/xemacs/src/insdel.c, line 364, VALID_CHARPTR_P (ptr) [2]+ IOT trap/Abort (core dumped) /home/evermann/src/XEmacs/mule/src/xemacs #0 0x403c6405 in __kill () #1 0x40393055 in raise (sig=136599168) #2 0x8129964 in bytecount_to_charcount (ptr=0x8ecfe4e "£\b\n ", len=37) at /local/srcdisk/gunnar/src/XEmacs/xemacs/src/insdel.c:364 #3 0x80c80c0 in string_char_length (s=0x8d44684) at /local/srcdisk/gunnar/src/XEmacs/xemacs/src/lisp.h:1121 #4 0x814c22d in print_string (obj=148129412, printcharfun=138121120, escapeflag=1) at /local/srcdisk/gunnar/src/XEmacs/xemacs/src/print.c:953 #5 0x814c9ab in print_internal (obj=148129412, printcharfun=138121120, escapeflag=1) at /local/srcdisk/gunnar/src/XEmacs/xemacs/src/print.c:1227 #6 0x814b231 in Fprin1 (object=148129412, stream=138121120) at /local/srcdisk/gunnar/src/XEmacs/xemacs/src/print.c:508 #7 0x8096a98 in Fbacktrace (stream=138121120, detailed=138008936) at /local/srcdisk/gunnar/src/XEmacs/xemacs/src/eval.c:4868 #8 0x808a8cf in fatal_error_signal (sig=6) at /local/srcdisk/gunnar/src/XEmacs/xemacs/src/emacs.c:252 #9 0xbfffed24 in ?? () #10 0x40393055 in raise (sig=136599168) #11 0x8129964 in bytecount_to_charcount (ptr=0x8ecfe4e "£\b\n ", len=37) at /local/srcdisk/gunnar/src/XEmacs/xemacs/src/insdel.c:364 #12 0x80c80c0 in string_char_length (s=0x8d44684) at /local/srcdisk/gunnar/src/XEmacs/xemacs/src/lisp.h:1121 #13 0x812b7c9 in get_string_range_char (string=148129412, from=1, to=1, from_out=0xbfffee64, to_out=0xbfffee60, flags=3) at /local/srcdisk/gunnar/src/XEmacs/xemacs/src/insdel.c:1352 #14 0x812b903 in get_string_range_byte (string=148129412, from=1, to=1, from_out=0xbfffeeec, to_out=0xbfffeee8, flags=3) at /local/srcdisk/gunnar/src/XEmacs/xemacs/src/insdel.c:1391 #15 0x812bae5 in get_buffer_or_string_range_byte (object=148129412, from=1, to=1, from_out=0xbfffeeec, to_out=0xbfffeee8, flags=3) at /local/srcdisk/gunnar/src/XEmacs/xemacs/src/insdel.c:1438 #16 0x80e8d2c in Fmap_extents (function=142000648, object=148129412, from=1, to=1, maparg=138008908, flags=138008908, property=140724204, value=138008908) at /local/srcdisk/gunnar/src/XEmacs/xemacs/src/extents.c:4049 #17 0x809379a in Ffuncall (nargs=8, args=0xbfffefa4) at /local/srcdisk/gunnar/src/XEmacs/xemacs/src/eval.c:3189 #18 0x8063395 in execute_optimized_program ( program=0x87eeed4 "\b¬\003Á\207\n«\006Ã\n!ª\002p\034\n«\006Å\n!ª\003Æ \036\a\n«\006È\n!ª\002`\036\t\n\004Ê\n!\211\036\013\017ÌÍÎÏ\f\"\016\013\211Ð\211Ñ&\a\036\022\n\004Ó\n!\211\036\024\nÕ\016\024Ñ\"\003\016\024\036\024\016\t\aÖ\016\t\fÑ#\036\027\n\004Ø\n!\211\036\031\tÚ\016\031!\003\016\031\036\031\016\022®\013\016\024®\a\016\027®\003\016\031\036\e\016\034\036\035\016\e¬(\016\036\205>\001\016\a\016\036a?\2055\001Ð\026\037\016\035«\tà\016\035!\210Ð\026\034á \205!\001â \202\034\001ã\016\a!\036$å\016$·A\036%æ\016$·"..., stack_depth=9, constants_data=0x8666208) at /local/srcdisk/gunnar/src/XEmacs/xemacs/src/bytecode.c:754 #19 0x8062e9a in funcall_compiled_function (fun=142000676, nargs=1, args=0xbffff1bc) at /local/srcdisk/gunnar/src/XEmacs/xemacs/src/bytecode.c:527 #20 0x809388b in Ffuncall (nargs=2, args=0xbffff1b8) at /local/srcdisk/gunnar/src/XEmacs/xemacs/src/eval.c:3221 #21 0x8094668 in run_hook_with_args_in_buffer (buf=0x8de2aa8, nargs=2, args=0xbffff1b8, cond=RUN_HOOKS_TO_COMPLETION) at /local/srcdisk/gunnar/src/XEmacs/xemacs/src/eval.c:3671 #22 0x80946be in run_hook_with_args (nargs=2, args=0xbffff1b8, cond=RUN_HOOKS_TO_COMPLETION) at /local/srcdisk/gunnar/src/XEmacs/xemacs/src/eval.c:3684 #23 0x8094356 in Frun_hook_with_args (nargs=2, args=0xbffff1b8) at /local/srcdisk/gunnar/src/XEmacs/xemacs/src/eval.c:3560 #24 0x8093836 in Ffuncall (nargs=3, args=0xbffff1b4) at /local/srcdisk/gunnar/src/XEmacs/xemacs/src/eval.c:3206 #25 0x8063395 in execute_optimized_program (program=0x87eeeb4 "ÀÁ\n\"\207\200\006\tñ\001", stack_depth=3, constants_data=0x869fb50) at /local/srcdisk/gunnar/src/XEmacs/xemacs/src/bytecode.c:754 #26 0x8062e9a in funcall_compiled_function (fun=142000536, nargs=1, args=0xbffff2dc) at /local/srcdisk/gunnar/src/XEmacs/xemacs/src/bytecode.c:527 #27 0x809388b in Ffuncall (nargs=2, args=0xbffff2d8) at /local/srcdisk/gunnar/src/XEmacs/xemacs/src/eval.c:3221 #28 0x809498e in call1 (fn=140924928, arg0=148491944) at /local/srcdisk/gunnar/src/XEmacs/xemacs/src/eval.c:3834 #29 0x80dd6bf in execute_internal_event (event=148491944) at /local/srcdisk/gunnar/src/XEmacs/xemacs/src/event-stream.c:2952 #30 0x80e0420 in Fdispatch_event (event=148491944) at /local/srcdisk/gunnar/src/XEmacs/xemacs/src/event-stream.c:4689 #31 0x8070bbb in Fcommand_loop_1 () at /local/srcdisk/gunnar/src/XEmacs/xemacs/src/cmdloop.c:578 #32 0x8070989 in command_loop_1 (dummy=138008908) at /local/srcdisk/gunnar/src/XEmacs/xemacs/src/cmdloop.c:493 #33 0x809021a in condition_case_1 (handlers=138009020, bfun=0x8070968 <command_loop_1>, barg=138008908, hfun=0x807023c <cmd_error>, harg=138008908) at /local/srcdisk/gunnar/src/XEmacs/xemacs/src/eval.c:1640 #34 0x8070341 in command_loop_3 () at /local/srcdisk/gunnar/src/XEmacs/xemacs/src/cmdloop.c:255 #35 0x8070364 in command_loop_2 (dummy=138008908) at /local/srcdisk/gunnar/src/XEmacs/xemacs/src/cmdloop.c:266 #36 0x808fe49 in internal_catch (tag=138083952, func=0x807035c <command_loop_2>, arg=138008908, threw=0x0) at /local/srcdisk/gunnar/src/XEmacs/xemacs/src/eval.c:1315 #37 0x8070578 in initial_command_loop (load_me=138008908) at /local/srcdisk/gunnar/src/XEmacs/xemacs/src/cmdloop.c:304 #38 0x808bb52 in xemacs_21_2_b12_i586_pc_linux (argc=1, argv=0xbffff530, envp=0xbffff538, restart=0) at /local/srcdisk/gunnar/src/XEmacs/xemacs/src/emacs.c:1736 #39 0x808c6d7 in main (argc=1, argv=0xbffff530, envp=0xbffff538) at /local/srcdisk/gunnar/src/XEmacs/xemacs/src/emacs.c:2165 #40 0x80507de in _start () -- Gunnar Evermann Speech, Vision & Robotics Group Engineering Department Cambridge University

1 participants
0 comments

Re: Fix for crash: skip-syntax-backward("_w") 25 years, 8 months

Hrvoje Niksic

Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes: > If this goes in shouldn't there at least be a comment in the code, Yes, there should. I complained about it to Martin.

1 participants
0 comments

Bug in PCL-CVS release R-2_0-Beta_2 25 years, 8 months

Geoffrey Furnish

Hello, I am running a recent XEmacs beta, version 21.0.65, with the xemacs-sumo tarball from 3/5/99. I just noticed that there is a bug in the included PCL-CVS mode. What happens is that I marked two files, and committed them. This was done, however, the "ci" notice was not removed from them. When I subsequently hit 'x', both files were removed from the display, as they should've been. So the problem is just that the "ci" indicator didn't disappear when it was supposed to. I have noticed that this does work correctly with unmarked files. In that case, the "ci" disappears after the commit completes. Let me know if I can provide any additional information. -- Geoffrey Furnish Actel Corporation furnish(a)actel.com Senior Staff Engineer 955 East Arques Ave voice: 408-522-7528 Placement & Routing Sunnyvale, CA 94086-4533 fax: 408-328-2303

1 participants
0 comments

Re: Fix for crash: skip-syntax-backward("_w") 25 years, 8 months

Gunnar Evermann

Martin Buchholz <martin(a)xemacs.org> writes: > This is a workaround for a compiler bug. > > For 21.0. There will be a much more aggressive patch for 21.2. > > 1999-03-10 Martin Buchholz <martin(a)xemacs.org> > > * search.c (skip_chars): Work around gcc compiler bug. > Fix long-suffering skip-syntax-backward crash. I personally think this is a Good Thing[TM] but didn't we decide not to work around this bug? I remember posting a question about this some time ago (although I hadn't actually tried doing it). If this goes in shouldn't there at least be a comment in the code, otherwise someone might just undo this during the next code fiddling attack :-) Gunnar -- Gunnar Evermann Speech, Vision & Robotics Group Engineering Department Cambridge University

1 participants
0 comments

Re: [21.0, repost with more Rationale] Mix X resources with Custom 25 years, 8 months

Jan Vroonhof

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > - One could argue this is the right interpretation. That attributes > arguments in the custom spec are just a form of writing minimal > data. However I think the way the customize face editor is I meant: That attributes FAILING in the custom spec are just a form of writing minimal data. Jan

1 participants
0 comments

patch: Emacs fix for footnote.el.0.19 25 years, 8 months

Jari Aalto

Hi, I saw reference to this cool package in Gnus group and immediately grabbed it from ftp://ftp.xemacs.org/pub/xemacs/packages/. There was small error for Emacs, otherwise works fine. jari

1 participants
0 comments

Re: Package update problem 25 years, 8 months

Jan Vroonhof

Adrian Aichner <aichner(a)ecf.teradyne.com> writes: > (md5 (with-temp-buffer > (insert-file-contents "c:\\temp\\texinfo-3_12.tar.gz") > (buffer-string))) > "731f0955cdaa5260d0f81053576a6482" If these don't match, try double checking using a stand alone md5 program. Jan

1 participants
0 comments

shadows elib vs. pcl-cvs 25 years, 8 months

Neal D. Becker

/usr/local/tools/xemacs/lib/xemacs/xemacs-packages/lisp/elib/elib-node hides /usr/local/tools/xemacs/lib/xemacs/xemacs-packages/lisp/pcl-cvs/elib-node /usr/local/tools/xemacs/lib/xemacs/xemacs-packages/lisp/elib/dll hides /usr/local/tools/xemacs/lib/xemacs/xemacs-packages/lisp/pcl-cvs/dll /usr/local/tools/xemacs/lib/xemacs/xemacs-packages/lisp/elib/dll-debug hides /usr/local/tools/xemacs/lib/xemacs/xemacs-packages/lisp/pcl-cvs/dll-debug /usr/local/tools/xemacs/lib/xemacs/xemacs-packages/lisp/elib/cookie hides /usr/local/tools/xemacs/lib/xemacs/xemacs-packages/lisp/pcl-cvs/cookie

1 participants
0 comments

RE: Package update problem 25 years, 8 months

Ian MacKinnon

gnus-1.39-pkg.tar.gz eval as below gives 0f412b7e791616213c70df1ab5d4aca8 while package-get-base gives 5413e7508693bfcb16c5a4a0e0bce7c7 --- Ian > -----Original Message----- > From: Adrian Aichner [mailto:aichner＠ecf.teradyne.com] > Sent: 10 March 1999 13:57 > To: xemacs-beta(a)xemacs.org > Subject: Re: Package update problem > > > >>>>> "Ian" == Ian MacKinnon <IMacKinnon(a)TELIA.CO.UK> writes: > > Ian> Hi all, When I try a package update (pick a package, any > Ian> package) it fails saying that the downloaded package does not > Ian> match the md5 checksum. This is 21.2.12 ( but I've seen it > Ian> in earlier releases) on cygwin b20 under NT What am I doing > Ian> wrong ? > > Hi Ian, > > try this on the file in question, e.g. texinfo-3_12.tar.gz: > > (md5 (with-temp-buffer > (insert-file-contents "c:\\temp\\texinfo-3_12.tar.gz") > (buffer-string))) > "731f0955cdaa5260d0f81053576a6482" > > Compare the result with the information in `package-get-base' after > evaluating > (package-get-require-base) > > Adrian > > Ian> --- > Ian> Ian > > -- > Adrian Aichner Teradyne GmbH, European Design Center > Integra Test Division Telephone +49/89/41861(0)-208 > Dingolfinger Strasse 2 Fax +49/89/41861-217 > (What is a Fax?) > D-81673 MUENCHEN E-mail adrian.aichner(a)teradyne.com >

1 participants
0 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta March 1999