April 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Re: assertion failed; looks like a bug 24 years, 2 months

Jan Vroonhof

[Please remove xemacs-patches from CC when replying] Hamish Macdonald <hamishm(a)lucent.com> writes: Superb bug report... > I discovered that when attempting to do some piping in eshell > (e.g. "ls | head"), my XEmacs was dying. I started to do some > investigation. > > I got the following backtrace: > #0 assert_failed (file=0x22bda8 "lstream.h", line=33, > expr=0x22bdb8 "RECORD_TYPEP (obj, lrecord_type_lstream)") at emacs.c:2748 > #1 0xdace4 in unix_send_process (proc=5188096, lstream=0x37fc00) > at lstream.h:33 > #2 0x167b38 in send_process (proc=5188096, relocatable=5573876, > nonrelocatable=0x0, start=0, len=315) at process.c:988 > #3 0x16a2a8 in Fprocess_send_string (process=5188096, string=5573876, > from=-24697440, to=-24697440) at process.c:1118 > > This backtrace is actually somewhat misleading, since the lstream > passed in to unix_send_process is perfectly valid. The lstream that is > being barfed on in p->pipe_outstream (where p is the process structure > referred to by Lisp_Object argument proc. > > [...] > >> XLSTREAM(p->pipe_outstream) as an argument. At this point, > p->p->pipe_outstream is no longer an lstream, but is nil; > the assertion fails, BOOM. > > I'm not sure what the correct fix is here. Since it is perfectly normal for a process to die while processing events we have to guard against after calls that process events.. I think the following simple bailout is the correct solution 2000-04-11 Jan Vroonhof <jan(a)xemacs.org> * process-unix.c (unix_send_process): Guard against process MIA after Faccept_process_output. Index: process-unix.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs-20/src/process-unix.c,v retrieving revision 1.11.2.18 diff -u -r1.11.2.18 process-unix.c --- process-unix.c 2000/03/01 18:22:05 1.11.2.18 +++ process-unix.c 2000/04/11 10:31:19 ＠＠ -1139,6 +1139,14 ＠＠ volatile Lisp_Object vol_proc = proc; Lisp_Process *volatile p = XPROCESS (proc); + /* #### JV: layering violation? + + This function knows too much about the relation between the encodingstream + (DATA_OUTSTREAM) and te actual output stream p->output_stream. + + If encoding streams properly forwarded all calls, we could simply + use DATA_OUTSTREAM everywhere. */ + if (!SETJMP (send_process_frame)) { /* use a reasonable-sized buffer (somewhere around the size of the ＠＠ -1173,6 +1181,9 ＠＠ that may allow the program to finish doing output and read more. */ Faccept_process_output (Qnil, make_int (1), Qnil); + /* It could have *really* finished, deleting the process */ + if (NILP(p->pipe_outstream)) + return; old_sigpipe = (SIGTYPE (*) (int)) signal (SIGPIPE, send_process_trap); Lstream_flush (XLSTREAM (p->pipe_outstream));

1 participants
0 comments

Re: uniquify and custom 24 years, 2 months

Jan Vroonhof

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > John> '(uniquify-buffer-name-style (quote post-forward-angle-brackets)) > > John> in the variables section - great > > John> however, it doesn't seem to work unless I still put a > > John> (require 'uniquify) > > John> before the custom-set stuff > > John> that shouldn't be necessary, should it? It shouldn't. > Custom doesn't know about package dependencies, if that's what you > mean. So uniquify )or any other package) won't get used at all unless > it is require'd or autoloaded somewhere. Custom doesn't do that for > you at this point. No this is a case that customize can handle (because it is so common). I guess uniquify needs a :require in the defcustom of its main enabling variable. Jan

1 participants
0 comments

Re: [BUGS] #include oddity in v7.0b3 24 years, 2 months

Didier Verna

Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > The usual way to do this is to detect the location and then add a -I > switch to your compile switches. But I suppose XEmacs is smarter than > every other project on the planet. Please tell me M. Lane, what makes you react so aggressively ? > Where in the ANSI C spec does it say that #include "" behaves that way > and #include <> doesn't? Where does it even say that you're allowed to > specify a path in #include at all? C'mon. This is pure and simple bad faith. Postgresql itself has examples of using "" and <>, and paths in inclusion macros. Don't get me wrong on this: all XEmacs strictly requires to compile is an ANSI C compiler. > It seems to me you are treating an implementation choice made by your > compiler as gospel. (Yes, I know gcc behaves that way.) *your* compiler ? XEmacs compiles on Suns, PCs (Unix and Windows), HPs, SGIs, DECs with gcc but native compilers also. That makes a lot of platforms. On all of these platforms, the preprocessor works the way the ANSI C spec doesn't specify. Geeze, if we follow your reasoning, one couldn't even compile the simplest X11 application. > I should make it clear that I agree with you: include "" makes more > sense than include <> in this context, That's surprising to hear, to say the least. > and IIRC I argued against changing it at the time. But I can't see putting > much weight on arguments that are based on a practice as unusual and > non-standards- compliant as putting full paths directly into #include > commands. I'm sorry about this, I should have made it clearer. It's not full path actually. On my debian woody system, it expands to: #include <postgresql/libpq-fe.h> just like you would #include <X11/Intrinsic.h> and _this doesn't work anymore_. > In the normal context where search paths are driven by -I, it won't matter > which form we use. The context you're talking about is not more "normal" than any other. -I is broken by concept in many respects. But the most important is that dozens of -I on the command line is actually not portable because command lines too long can break some systems. Standards are a good think, but we're concerned by portability first. > Give me a better reason, and I'll change it back. But I don't want > to have to explain to the other guy that we're not going to support > his situation just to make the world safe for an arguably broken > coding method, even if it is one used by a project as big as XEmacs. "The other guy" for sure must do something as broken as we do. The size of XEmacs has nothing to do with this. Tom, let me make this clear: we support many different packages differently installed on different platforms. We always try to be as compliant as possible with the standards, and write tricks for very special cases only. When such tricks are needed, we hide them as much as possible (most of the time under the form of a configure test and one or two macros). The way we include `libpq-fe.h' (see above) is not unusual at all. Currently, *only* postgres 7.0 breaks this scheme. That sounds to me as a good enough reason. One more thing: I was trying to have a constructive discussion with you. We could perfectly well make a special case for postgresql. No problem. We do that already for soooo many broken stuff that we support. However, my policy has always been to try to try first to cooperate with external software developers before writing tricks. I don't know if something was wrong in my english wording, but I must say that in this context, I'm rather upset by your reaction. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / EPITA / LRDE mailto:didier＠lrde.epita.fr /_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 44 08 01 77 94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99

1 participants
0 comments

crash in execute_rare_bytecode() 24 years, 2 months

Ben Wing

I've seen something like this before, awhile ago. I have no idea what's the cause, but it could be Martin's, since he definitely did a lot of work in this area not long ago. (And furthermore, there are no tell-tale signs at all of an Andy-like problem.) Here's the call stack: NTDLL! 77f9d715() execute_rare_opcode(long * 0x0082d728, unsigned char * 0x0204204e, int 190) line 1482 + 20 bytes execute_optimized_program(unsigned char * 0x02046810, int 4, long * 0x02046010) line 657 + 17 bytes funcall_compiled_function(long 34290956, int 0, long * 0x0082da04) line 519 + 53 bytes Ffuncall(int 1, long * 0x0082da00) line 3476 + 17 bytes call0(long 30307220) line 4081 + 11 bytes Fset_buffer_major_mode(long 32897024) line 1468 + 9 bytes Ffuncall(int 2, long * 0x0082da9c) line 3441 + 66 bytes execute_optimized_program(unsigned char * 0x0082dc7c, int 3, long * 0x01c6ab10) line 751 + 16 bytes Fbyte_code(long 29837236, long 29797120, long 7) line 2410 + 38 bytes Feval(long 29715792) line 3241 + 187 bytes condition_case_1(long 29665668, long (long)* 0x0106a1d3 Feval(long), long 29715792, long (long, long)* 0x0106792b run_condition_case_handlers(long, long), long 28478044) line 1815 + 7 bytes condition_case_3(long 29715792, long 28478044, long 29665668) line 1899 + 27 bytes execute_rare_opcode(long * 0x0082e018, unsigned char * 0x01e6ff04, int 143) line 1276 + 19 bytes execute_optimized_program(unsigned char * 0x01e6fe10, int 6, long * 0x01c73f10) line 657 + 17 bytes funcall_compiled_function(long 29789760, int 1, long * 0x0082e2fc) line 519 + 53 bytes Ffuncall(int 2, long * 0x0082e2f8) line 3476 + 17 bytes execute_optimized_program(unsigned char * 0x01da6c10, int 7, long * 0x01e67510) line 751 + 16 bytes funcall_compiled_function(long 32123864, int 3, long * 0x0082e5dc) line 519 + 53 bytes Ffuncall(int 4, long * 0x0082e5d8) line 3476 + 17 bytes Fapply(int 3, long * 0x0082e6d0) line 3717 + 13 bytes Ffuncall(int 4, long * 0x0082e6cc) line 3462 + 14 bytes execute_optimized_program(unsigned char * 0x0082e8b8, int 6, long * 0x01e67110) line 751 + 16 bytes Fbyte_code(long 31713764, long 31879424, long 13) line 2410 + 38 bytes Feval(long 32841352) line 3241 + 187 bytes internal_catch(long 32717332, long (long)* 0x0106a1d3 Feval(long), long 32841352, int * 0x00000000, long * 0x00000000) line 1478 + 7 bytes execute_rare_opcode(long * 0x0082eec8, unsigned char * 0x01f7e9b1, int 141) line 1257 + 24 bytes execute_optimized_program(unsigned char * 0x01f7e990, int 5, long * 0x01f7e210) line 657 + 17 bytes funcall_compiled_function(long 32123808, int 2, long * 0x0082f1ac) line 519 + 53 bytes Ffuncall(int 3, long * 0x0082f1a8) line 3476 + 17 bytes execute_optimized_program(unsigned char * 0x01f1b550, int 4, long * 0x01f61c10) line 751 + 16 bytes funcall_compiled_function(long 32123724, int 1, long * 0x0082f480) line 519 + 53 bytes Ffuncall(int 2, long * 0x0082f47c) line 3476 + 17 bytes execute_optimized_program(unsigned char * 0x01b05290, int 4, long * 0x01f7e310) line 751 + 16 bytes funcall_compiled_function(long 32123640, int 0, long * 0x0082f758) line 519 + 53 bytes Ffuncall(int 1, long * 0x0082f754) line 3476 + 17 bytes execute_optimized_program(unsigned char * 0x01def4d0, int 2, long * 0x01f790f0) line 751 + 16 bytes funcall_compiled_function(long 32123612, int 1, long * 0x0082fa24) line 519 + 53 bytes Ffuncall(int 2, long * 0x0082fa20) line 3476 + 17 bytes Fcall_interactively(long 33046188, long 28356612, long 28356612) line 942 + 22 bytes Fcommand_execute(long 33046188, long 28356612, long 28356612) line 2888 + 17 bytes execute_command_event(command_builder * 0x01d59680, long 33589428) line 3879 + 25 bytes Fdispatch_event(long 33589428) line 4206 + 70 bytes Fcommand_loop_1() line 565 + 9 bytes command_loop_1(long 28356612) line 491 condition_case_1(long 28356708, long (long)* 0x0104a26d command_loop_1(long), long 28356612, long (long, long)* 0x01049c80 cmd_error(long, long), long 28356612) line 1815 + 7 bytes command_loop_3() line 252 + 35 bytes command_loop_2(long 28356612) line 264 internal_catch(long 28434436, long (long)* 0x01049dd0 command_loop_2(long), long 28356612, int * 0x00000000, long * 0x00000000) line 1478 + 7 bytes initial_command_loop(long 28356612) line 301 + 27 bytes STACK_TRACE_EYE_CATCHER(int 1, char * * 0x01b49500, char * * 0x01b05680, int 0) line 2010 + 9 bytes main(int 1, char * * 0x01b49500, char * * 0x01b05680) line 2439 + 21 bytes mainCRTStartup + 211 bytes _start() line 183 KERNEL32! 77e9bc52() and here's the scoop: In execute_optimized_program, the bad opcode is 190, and the pointer to the beginning of the program array is at 0x02046810. However, the pointer to the current location in the program array, stored in program_ptr, is 0x0204204e -- which is nowhere near the array! That's almost certainly the fuckup. I've enclosed a memory dump of the program array, and in it you should be able to find the instruction causing the problem and see if you can figure out why this is happening. Martin, I suggest really putting in some sanity checks in the execution of the byte code, controlled by ERROR_CHECK_BYTE_CODE, to check for this kind of stuff and all sorts of other possibilities. If this can occur, there might be a whole bunch of problems that could be occurring, most of the time causing no harm but every once in awhile fucking something else up in a strange, difficult to debug way. I can imagine already that you're going to grumble about the performance loss, but that's a given with error-checking, and it's saved our asses way many times. + program,m 0x02046810 d0 10 e7 01 54 8f b4 01 b4 8f b4 01 84 27 b8 01 ....T........'.. + program+16,m 0x02046820 8c 2d bf 01 cc e7 c1 01 e4 f1 b1 01 cc e7 c1 01 .-.............. + program+32,m 0x02046830 8c 2d bf 01 84 27 b8 01 8c 2d bf 01 fc b4 b5 01 .-...'...-...... + program+48,m 0x02046840 1c b0 b0 01 e4 f1 b1 01 24 8f b4 01 cc e7 c1 01 ........$....... + program+64,m 0x02046850 dc fe c3 01 64 4b c1 01 e4 f1 b1 01 b4 c4 bb 01 ....dK.......... + program+80,m 0x02046860 b4 8f b4 01 c4 60 bd 01 1c b0 b0 01 dc fe c3 01 .....`.......... + program+96,m 0x02046870 cc e7 c1 01 1c 9b b2 01 34 43 b2 01 08 19 0a c3 ........4C...... + program+112,m 0x02046880 16 68 04 02 40 6c 08 02 45 e8 00 00 40 00 00 00 .h..＠l..E...＠... + program+128,m 0x02046890 c0 20 ad 3c 09 ab 05 c2 20 aa 07 c3 c4 20 21 c5 . .<.... .... !. + program+144,m 0x020468a0 61 ad 2d 0e 06 3b ad 28 c7 0e 06 21 ad 22 0e 06 a.-..;.(...!.".. + program+160,m 0x020468b0 09 ab 09 c8 c9 ca 20 22 41 aa 08 cb cc cd 20 c9 ...... "A..... . + program+176,m 0x020468c0 22 21 98 3f ad 0a ce cd 20 c9 0e 06 42 43 22 87 "!.?.... ...BC". + program+192,m 0x020468d0 54 b3 04 02 76 69 70 65 72 2d 75 73 65 2d 72 65 T...viper-use-re -- Ben In order to save my hands, I am cutting back on my mail. I also write as succinctly as possible -- please don't be offended. If you send me mail, you _will_ get a response, but please be patient, especially for XEmacs-related mail. If you need an immediate response and it is not apparent in your message, please say so. Thanks for your understanding. See also http://www.666.com/ben/typing.html.

1 participants
0 comments

Freeze 21.2.b32: X Error of failed request: BadWindow (invalid Window parameter) 24 years, 2 months

Ulrich Kaage

Hi, after the text image fix, here is a new bug report :-) XEmacs version as of today (emacs-version) "XEmacs 21.2 (beta32) \"Kastor & Polydeukes\" [Lucid] (sparc-sun-solaris2.6, Mule) of Tue Apr 11 2000 on inss24" system-configuration-options "--prefix=/usr/users/kaage/lib/xemacs --dynamic=yes --with-dialogs=athena --with-site-lisp --with-mule" Originally, I wanted to trace down a SEGFAULT being produced while heavily using gnuclient. Unfortunately, this bug was not reproducible with a vanilla XEmacs. Instead, a freeze occurred. I've started xemacs -vanilla. After starting gnuserv, I've loaded an html file via gnuclient. Now, repeated quitting of the file via C-x # and loading again with gnuclient after about 20 cycles yields to a freeze of XEmacs including the following X error: xemacs: X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 8 (X_MapWindow) Resource id in failed request: 0x2c001d3 Serial number of failed request: 15906 Current serial number in output stream: 15916 Attaching with GDB shows where XEmacs is frozen: Attaching to program `/usr/users/kaage/lib/xemacs/bin/xemacs-21.2-b32', process 15292 Symbols already loaded for /lib/libXm.so.3 Symbols already loaded for /lib/libXaw.so.5 Symbols already loaded for /usr/openwin/lib/libtiff.so Symbols already loaded for /tools/misc/lib/libpng.so.2 Symbols already loaded for /tools/misc/lib/libjpeg.so.62 Symbols already loaded for /usr/openwin/lib/libtt.so.2 Symbols already loaded for /lib/libXmu.so.4 Symbols already loaded for /lib/libXt.so.4 Symbols already loaded for /lib/libXext.so.0 Symbols already loaded for /lib/libX11.so.4 Symbols already loaded for /lib/libdl.so.1 Symbols already loaded for /lib/libkstat.so.1 Symbols already loaded for /lib/libm.so.1 Symbols already loaded for /lib/libsocket.so.1 Symbols already loaded for /lib/libnsl.so.1 Symbols already loaded for /lib/libc.so.1 Symbols already loaded for /tools/misc/lib/libz.so.1.1.3 Symbols already loaded for /lib/libSM.so.6 Symbols already loaded for /lib/libICE.so.6 Symbols already loaded for /lib/libmp.so.2 Symbols already loaded for /lib/libXm.so.3 Symbols already loaded for /lib/libXaw.so.5 Symbols already loaded for /usr/openwin/lib/libtiff.so Symbols already loaded for /tools/misc/lib/libpng.so.2 Symbols already loaded for /tools/misc/lib/libjpeg.so.62 Symbols already loaded for /usr/openwin/lib/libtt.so.2 Symbols already loaded for /lib/libXmu.so.4 Symbols already loaded for /lib/libXt.so.4 Symbols already loaded for /lib/libXext.so.0 Symbols already loaded for /lib/libX11.so.4 Symbols already loaded for /lib/libdl.so.1 Symbols already loaded for /lib/libkstat.so.1 Symbols already loaded for /lib/libm.so.1 Symbols already loaded for /lib/libsocket.so.1 Symbols already loaded for /lib/libnsl.so.1 Symbols already loaded for /lib/libc.so.1 Symbols already loaded for /tools/misc/lib/libz.so.1.1.3 Symbols already loaded for /lib/libSM.so.6 Symbols already loaded for /lib/libICE.so.6 Symbols already loaded for /lib/libmp.so.2 0xef0b7318 in poll () from /lib/libc.so.1 (gdb) where #0 0xef0b7318 in poll () from /lib/libc.so.1 #1 0xef0ccb24 in select () from /lib/libc.so.1 #2 0xef2cdf94 in _XWaitForReadable () from /lib/libX11.so.4 #3 0xef28f3d8 in _XRead () from /lib/libX11.so.4 #4 0xef2918ec in _XReply () from /lib/libX11.so.4 #5 0xef2a51bc in XQueryColor () from /lib/libX11.so.4 #6 0x20757c in x_generate_shadow_pixels (f=0x65c800, top_shadow=0xefffe524, bottom_shadow=0xefffe520, background=15066597, core_background=15066597) at redisplay-x.c:1609 #7 0x20450c in x_bevel_area (w=0x85f800, findex=1, x=4, y=584, width=735, height=18, shadow_thickness=2, edges=15, style=EDGE_BEVEL_OUT) at redisplay-x.c:549 #8 0x1b1eb8 in bevel_modeline (w=0x85f800, dl=0x803000) at redisplay-output.c:2344 #9 0x204254 in x_output_display_block (w=0x85f800, dl=0x803000, block=0, start=1, end=82, start_pixpos=4, cursor_start=0, cursor_width=0, cursor_height=0) at redisplay-x.c:507 #10 0x1ae398 in redisplay_output_display_block (w=0x85f800, dl=0x803000, block=0, start=1, end=82, start_pixpos=0, cursor_start=0, cursor_width=0, cursor_height=0) at redisplay-output.c:1134 #11 0x1acf9c in output_display_line (w=0x85f800, cdla=0x6f0340, ddla=0x6f0940, line=0, force_start=4, force_end=739) at redisplay-output.c:650 #12 0x1b18d4 in redisplay_output_window (w=0x85f800) at redisplay-output.c:2256 ---Type <return> to continue, or q <return> to quit--- #13 0x1a1ae4 in redisplay_window (window=8779776, skip_selected=1) at redisplay.c:6243 #14 0x1a2148 in redisplay_frame (f=0x82a400, preemption_check=0) at redisplay.c:6455 #15 0x1a23b4 in redisplay_device (d=0x658d00, automatic=8561664) at redisplay.c:6533 #16 0x1a2934 in redisplay_without_hooks () at redisplay.c:6622 #17 0x1a2bb4 in redisplay () at redisplay.c:6679 #18 0xfc588 in Fnext_event (event=6709948, prompt=3131396) at event-stream.c:2180 #19 0x88444 in Fcommand_loop_1 () at cmdloop.c:566 #20 0x88194 in command_loop_1 (dummy=3131396) at cmdloop.c:490 #21 0xa9ff4 in condition_case_1 (handlers=3131492, bfun=0x88148 <command_loop_1>, barg=3131396, hfun=0x875f8 <cmd_error>, harg=3131396) at eval.c:1644 #22 0x8770c in command_loop_3 () at cmdloop.c:252 #23 0x8772c in command_loop_2 (dummy=3131396) at cmdloop.c:263 #24 0xa9adc in internal_catch (tag=3213556, func=0x87720 <command_loop_2>, arg=3131396, threw=0x0) at eval.c:1310 #25 0x87a90 in initial_command_loop (load_me=554784) at cmdloop.c:301 #26 0xa52ac in sort_args (argc=2921472, argv=0xeffff0f4) at emacs.c:1873 (gdb) Cheers, Uli

1 participants
0 comments

Re: Argh. ATHENA_INCLUDE strikes *again* 24 years, 2 months

Didier Verna

Vladis, Yoshiki-san, sorry for this late answer. I took some holidays in Guadeloupe[1] and just returned to work. Valdis.Kletnieks(a)vt.edu wrote: > OK, once we figured out that the AIX include scheme needed a simple include, > and not the double-redirection that didn't work, ATHENA_INCLUDE started > working fine. > > Now somebody made a '#define ATHENA_INCLUDE(a,b) SIMPLE_INCLUDE(a,b)', > which trips over the same AIX preprocessor bug that STARTED this whole > discussion. My fault. Thanks for the report, I see the problem. I'll look into both problems soon. Footnotes: [1] Air temperature: 30° Water temperature: 28° Rhum temperature: 55° -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / EPITA / LRDE mailto:didier＠epita.fr /_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 44 08 01 77 94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99

2 participants
1 comments

Re: #include oddity in v7.0b3 24 years, 2 months

Oliver Elphick

Didier Verna wrote: > >[ Cc'ed to the XEmacs development list and the postgres debian package > maintainer ] > > Hi! > > After upgrading my debian system (woody), the postgres package went >from 6.5 to 7.0b3. On debian linux boxes, the postgres headers are located >under /usr/include/postgresql/. > > The file `libpq-fe.h' #include's the file `postgres_ext.h' using <> >instead of "" (line 27). As a consequence, applications that just do: > >| #include <full/path/to/libpq-fe.h> > >can't build anymore because the file `postgres_ext.h' is not in the path. Th >is >happens to be the case for XEmacs. I believe this is a bug because: > >1/ this didn't happen with my former version 6.5 >2/ the usage of <> or "" doesn't seem to be coherent among the headers >3/ it's better to use "" when headers installed in the same place have to > include each others The Debian documentation used to include a statement that `-I/usr/include/postgresql' should be included in the compilation options. That seems to have got lost. -- Oliver Elphick Oliver.Elphick(a)lfix.co.uk Isle of Wight http://www.lfix.co.uk/oliver PGP key from public servers; key ID 32B8FAA1 ======================================== "But seek ye first the kingdom of God, and his righteousness; and all these things shall be added unto you." Matthew 6:33

1 participants
0 comments

another exciting installment of "crashes in VM" 24 years, 2 months

John A. Turner

as always, env as in: http://www.xemacs.org/list-archives/xemacs-beta/200003/msg00021.html but 21.2b32, CVS update a few days ago crashes have decreased *significantly* - this is the first in days: Program received signal SIGSEGV, Segmentation fault. GetToken () at Shell.c:3256 3256 Shell.c: No such file or directory. (gdb) where #0 GetToken () at Shell.c:3256 #1 0x1026ee78 in x_map_subwindow (p=0x10e47280, x=0, y=0, dga=0x7fff1dd8) at glyphs-x.c:2153 #2 0x1016e66c in map_subwindow (subwindow=283406976, x=0, y=0, dga=0x7fff1dd8) at glyphs.c:4497 #3 0x10203ae4 in redisplay_output_subwindow (w=0x104ba800, image_instance=283406976, db=0x7fff1e90, dga=0x7fff1ea0, findex=6, cursor_start=0, cursor_width=0, cursor_height=0) at redisplay-output.c:1251 #4 0x10279540 in x_output_display_block (w=0x104ba800, dl=0x109cd400, block=0, start=0, end=1, start_pixpos=0, cursor_start=0, cursor_width=0, cursor_height=0) at redisplay-x.c:464 #5 0x10203608 in redisplay_output_display_block (w=0x104ba800, dl=0x109cd400, block=0, start=0, end=1, start_pixpos=0, cursor_start=0, cursor_width=0, cursor_height=0) at redisplay-output.c:1134 #6 0x10201104 in compare_display_blocks (w=0x104ba800, cdl=0x106d5000, ddl=0x109cd400, c_block=0, d_block=0, start_pixpos=0, cursor_start=0, cursor_width=0, cursor_height=0) at redisplay-output.c:522 #7 0x10201fe0 in output_display_line (w=0x104ba800, cdla=0x10c3aec0, ddla=0x10c3aea0, line=0, force_start=-1, force_end=-1) at redisplay-output.c:772 #8 0x1018eda8 in output_gutter (f=0x10b3d600, pos=TOP_GUTTER, force=0) at gutter.c:318 #9 0x101905ec in update_frame_gutters (f=0x10b3d600) at gutter.c:562 #10 0x101f2c80 in redisplay_frame (f=0x10b3d600, preemption_check=0) at redisplay.c:6415 #11 0x101f3314 in redisplay_device (d=0x105be800, automatic=1) at redisplay.c:6502 #12 0x101f3c90 in redisplay_without_hooks () at redisplay.c:6591 #13 0x101f3fa4 in redisplay () at redisplay.c:6648 #14 0x1010792c in Fnext_event (event=280548724, prompt=272336900) at event-stream.c:2180 #15 0x10076968 in Fcommand_loop_1 () at cmdloop.c:566 #16 0x100765ec in command_loop_1 (dummy=272336900) at cmdloop.c:490 #17 0x100ad044 in condition_case_1 (handlers=272336996, bfun=0x1007659c <command_loop_1>, barg=272336900, hfun=0x10075960 <cmd_error>, harg=272336900) at eval.c:1644 #18 0x10075b88 in command_loop_3 () at cmdloop.c:252 #19 0x10075bf8 in command_loop_2 (dummy=272336900) at cmdloop.c:263 #20 0x100ac8c8 in internal_catch (tag=272412644, func=0x10075bc4 <command_loop_2>, arg=272336900, threw=0x0) at eval.c:1310 #21 0x10075f30 in initial_command_loop (load_me=272336900) at cmdloop.c:301 #22 0x100a53f4 in xemacs_21_2_b32_mips_sgi_irix6_5 (argc=1, argv=0x7fff2e34, envp=0x7fff2e3c, restart=0) at emacs.c:1873 #23 0x100a6728 in main (argc=1, argv=0x7fff2e34, envp=0x7fff2e3c) at emacs.c:2292 no useful lbt -- John A. Turner, Senior Research Associate Blue Sky Studios, One South Rd, Harrison, NY 10528 http://www.blueskystudios.com/ (914) 825-8319

1 participants
0 comments

#include oddity in v7.0b3 24 years, 2 months

Didier Verna

[ Cc'ed to the XEmacs development list and the postgres debian package maintainer ] Hi! After upgrading my debian system (woody), the postgres package went from 6.5 to 7.0b3. On debian linux boxes, the postgres headers are located under /usr/include/postgresql/. The file `libpq-fe.h' #include's the file `postgres_ext.h' using <> instead of "" (line 27). As a consequence, applications that just do: | #include <full/path/to/libpq-fe.h> can't build anymore because the file `postgres_ext.h' is not in the path. This happens to be the case for XEmacs. I believe this is a bug because: 1/ this didn't happen with my former version 6.5 2/ the usage of <> or "" doesn't seem to be coherent among the headers 3/ it's better to use "" when headers installed in the same place have to include each others What do you think ? Was this change intentional ? Thanks. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / EPITA / LRDE mailto:didier＠lrde.epita.fr /_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 44 08 01 77 94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99

3 participants
2 comments

Re: [BUGS] #include oddity in v7.0b3 24 years, 2 months

Didier Verna

Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > > What do you think ? Was this change intentional ? > > It was. Someone else complained that the other way didn't work for them. > At least from the point of libpq, I think they were right. I don't understand why. Could you explain ? > Certainly hardcoding a full path into application source code is a > completely unportable way to do things... Obviously, we're smarter than that. I had simplified the example to point at the problem clearly. Since we've already encountered different possible locations for postgresql headers, we actually detect their location at configure time, #define a macro containing the path, and use something like #include <THE_PATH/the_file.h> (this is yet simplified, but that's the idea). But that's not the point. When an application has to include a single header from a library, and when this application knows where to find it, it should be able to include it directly without special cpp cooking. That's why headers installed in the same place should use "" and not <> to #include each others. The only valid reason for this change I can see is that libpq-fe.h and postgres_ext.h could happen to be installed at different locations. Can this be the case ? -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / EPITA / LRDE mailto:didier＠lrde.epita.fr /_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 44 08 01 77 94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99

4 participants
3 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 April 2000