Re: assertion failed; looks like a bug
24 years, 7 months
Jan Vroonhof
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, 7 months
Jan Vroonhof
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, 7 months
Didier Verna
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, 7 months
Ben Wing
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, 7 months
Ulrich Kaage
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, 7 months
Didier Verna
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, 7 months
Oliver Elphick
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, 7 months
John A. Turner
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, 7 months
Didier Verna
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, 7 months
Didier Verna
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