February 2000 - XEmacs-Beta - XEmacs Mailing List Archives

21.2.31 balloon-help crash on Solaris 2.7 24 years, 2 months

Raymond Toy

Built 21.2.31 from a full tarball on Solaris 2.7 using gcc 2.7.2.x. The following recipe gives me a 100% repeatable crash when balloon-help tries to pop up its help window. xemacs -vanilla In the *scratch* buffer, evaluate the following (balloon-help-mode) Now place the mouse over one of the toolbar buttons. Instant crash. Here's the Lisp backtrace: Lisp backtrace follows: # (unwind-protect ...) # (catch #<INTERNAL OBJECT (XEmacs bug?) (opaque_ptr, adr=0x2b31f8) 0x318000> ...) # (unwind-protect ...) # (unwind-protect ...) # bind (inhibit-quit) # (condition-case ... . error) # (catch top-level ...) Abort (core dumped) Here's the C backtrace: #0 0xfec16870 in _libc_kill () from /usr/lib/libc.so.1 #1 0xa3870 in fatal_error_signal (sig=6) at emacs.c:272 #2 <signal handler called> #3 0xfec16870 in _libc_kill () from /usr/lib/libc.so.1 #4 0xfebb92a4 in abort () from /usr/lib/libc.so.1 #5 0xa6598 in assert_failed (file=0x261ff8 "glyphs.h", line=808, expr=0x262058 "RECORD_TYPEP (obj, lrecord_type_glyph)") at emacs.c:2770 #6 0x147d5c in text_query_geometry (image_instance=7900800, width=0xffbed8e0, height=0xffbed8dc, disp=IMAGE_DESIRED_GEOMETRY, domain=7829504) at glyphs.c:1168 #7 0x13f91c in image_instance_layout (image_instance=7900800, width=4294967295, height=4294967295, domain=7829504) at glyphs.c:1699 #8 0x13c5cc in instantiate_image_instantiator (device=6454272, domain=7829504, instantiator=7779296, pointer_fg=6919424, pointer_bg=6700384, dest_mask=-1, glyph=3276160) at glyphs.c:615 #9 0x141f90 in image_instantiate (specifier=2599060, matchspec=6454272, domain=7829504, instantiator=7779296, depth=6919424) at glyphs.c:2831 #10 0xaa504 in call_with_suspended_errors_1 (opaque_arg=-4269120) at eval.c:2046 #11 0xaa924 in call_with_suspended_errors (fun=0x1419b4 <image_instantiate>, retval=2599060, class=3024900, errb=Cannot access memory at address 0x2a. ) at eval.c:1304 #12 0x1c1b4c in specifier_instance_from_inst_list (specifier=3560896, matchspec=2599060, domain=7829504, inst_list=6340592, errb=Cannot access memory at address 0x2a. ) at specifier.c:2455 #13 0x1c1f10 in specifier_instance (specifier=3560896, matchspec=2599060, domain=7829504, errb= Cannot access memory at address 0x2a. ) at specifier.c:2564 #14 0x116e90 in update_face_cachel_data (cachel=0xffbede28, domain=7829504, face=3276160) at faces.c:1194 #15 0x117abc in add_face_cachel (w=0x777800, face=3276160) at faces.c:1330 #16 0x117d38 in reset_face_cachels (w=0x777800) at faces.c:1361 #17 0x196c4c in redisplay_window (window=7829504, skip_selected=1) at redisplay.c:5936 #18 0x197ad8 in redisplay_frame (f=0x777a00, preemption_check=268435456) at redisplay.c:6410 #19 0x197ec0 in redisplay_device (d=0x627c00, automatic=7830016) at redisplay.c:6518 #20 0x1982ac in redisplay_without_hooks () at redisplay.c:6577 #21 0x198514 in redisplay () at redisplay.c:6634 #22 0xfbadc in Fnext_event (event=7662616, prompt=3024900) at event-stream.c:2238 #23 0x87708 in Fcommand_loop_1 () at cmdloop.c:566 #24 0x874ac in command_loop_1 (dummy=3024900) at cmdloop.c:490 #25 0xa9764 in condition_case_1 (handlers=2804736, bfun=0x87460 <command_loop_1>, barg=3024900, hfun=0x878f8 <cmd_error>, harg=3024900) at eval.c:1629 #26 0x87a08 in command_loop_2 (dummy=3024900) at cmdloop.c:252 #27 0xa9338 in internal_catch (tag=3107060, func=0x879bc <command_loop_2>, arg=3024900, threw=0x0) at eval.c:1304 #28 0x86de0 in initial_command_loop (load_me=555452) at cmdloop.c:301 #29 0xa540c in xemacs_21_2_b31_sparc_sun_solaris2_7 (argc=2, argv=0xffbeeb5c, envp=0xffbeeb68, restart=0) at emacs.c:1879 #30 0xa5c28 in main (argc=2, argv=0xffbeeb5c, envp=0xffbeeb68) at emacs.c:2305

2 participants
1 comments

Re: Buffer tabs still flickering 24 years, 2 months

Daniel Pittman

On 24 Feb 2000, Hrvoje Niksic <hniksic(a)iskon.hr> wrote: > Andy Piper <andy(a)xemacs.org> writes: > >> At 12:37 PM 2/24/00 +0100, Hrvoje Niksic wrote: [...] >> >P.S. Did I mention that it would be _really_ cool if the tabs >> >could somehow respect the background pixmap? The gutter looks very >> >ugly when the rest of the frame is pixmapized. >> >> You did, and I replied that it was currently impossible. > > The question was rhetorical. Still, I wonder if background support > could be added to the widget itself (there is something called > XPM-Athena apparently able to do these things). Er. Don't the standard Athena widgets implement the `backgroundPixmap' resource, which you can use to set the background image from the C code? Then Xaw-XPM allows you to set these from X resources, by name, rather than needing to support it in each application, or something. I think. If I am not misreading the Athena and Xaw-XPM stuff. > Could widget backgrounds work under Windows? Yes, they could, probably. It's possible, if difficult, to make that happen with most of the controls out there. So long as they don't do /really/ nasty, non standard things with their drawing.[1] Daniel Footnotes: [1] This does involve low-level hacking in the Windows drawing code and stuff, and subclassing someone else's drawing code. Which can be... interesting. -- I was part of that strange race of people aptly described as spending their lives doing things they detest to make money they don't want to buy things they don't need to impress people they dislike. -- Emile Henry Gauvreay

2 participants
1 comments

Re: Crash in latest 21.2 CVS 24 years, 2 months

Vin Shelton

>>>>> On Thu, 24 Feb 2000, Andy Piper <andy(a)xemacs.org> said: Andy> Your compiler has inlined some stuff, so its difficult to see which object Andy> its complaining about. Can you recompile glyphs.c with debugging on only Andy> (no optimization) and get another stack trace. I turned off the -O3 optimization altogether. Here's the backtrace: #0 0x40288d61 in __kill () from /lib/libc.so.6 #1 0x8087f91 in fatal_error_signal (sig=6) at /usr/local/src/xemacs-21.2-2000-02-24/src/emacs.c:272 #2 0x40288c98 in __restore () at ../sysdeps/unix/sysv/linux/i386/sigaction.c:127 #3 0x4028a1c0 in abort () at ../sysdeps/generic/abort.c:88 #4 0x808aa28 in assert_failed ( file=0x820dde0 "/usr/local/src/xemacs-21.2-2000-02-24/src/glyphs.h", line=816, expr=0x820de60 "RECORD_TYPEP (obj, lrecord_type_glyph)") at /usr/local/src/xemacs-21.2-2000-02-24/src/emacs.c:2770 #5 0x80b2d3d in error_check_glyph (obj=137325984) at /usr/local/src/xemacs-21.2-2000-02-24/src/glyphs.h:816 #6 0x81034c2 in text_query_geometry (image_instance=139893680, width=0xbffff1bc, height=0xbffff1b8, disp=IMAGE_DESIRED_GEOMETRY, domain=142114528) at /usr/local/src/xemacs-21.2-2000-02-24/src/glyphs.c:1998 #7 0x8102d1c in image_instance_layout (image_instance=139893680, width=4294967295, height=4294967295, domain=142114528) at /usr/local/src/xemacs-21.2-2000-02-24/src/glyphs.c:1707 #8 0x8100150 in instantiate_image_instantiator (device=137415288, domain=142114528, instantiator=141921608, pointer_fg=139512816, pointer_bg=139602584, dest_mask=-1, glyph=137325984) at /usr/local/src/xemacs-21.2-2000-02-24/src/glyphs.c:615 #9 0x8105602 in image_instantiate (specifier=137326352, matchspec=136595532, domain=142114528, instantiator=141921608, depth=3) at /usr/local/src/xemacs-21.2-2000-02-24/src/glyphs.c:2839 #10 0x808eff6 in call_with_suspended_errors_1 (opaque_arg=137297840) at /usr/local/src/xemacs-21.2-2000-02-24/src/eval.c:2046 #11 0x808dd52 in internal_catch (tag=137284584, func=0x808ee9c <call_with_suspended_errors_1>, arg=137297840, threw=0xbffff414) at /usr/local/src/xemacs-21.2-2000-02-24/src/eval.c:1304 #12 0x808f594 in call_with_suspended_errors (fun=0x81050ec <image_instantiate>, retval=136595532, class=137097236, errb={ really_unlikely_name_to_have_accidentally_in_a_non_errb_structure = 42}, nargs=5) at /usr/local/src/xemacs-21.2-2000-02-24/src/eval.c:2157 #13 0x8181c66 in specifier_instance_from_inst_list (specifier=137326352, matchspec=136595532, domain=142114528, inst_list=142137904, errb={ really_unlikely_name_to_have_accidentally_in_a_non_errb_structure = 42}, no_quit=1, depth=3) at /usr/local/src/xemacs-21.2-2000-02-24/src/specifier.c:2455 #14 0x8181fe6 in specifier_instance (specifier=137326352, matchspec=136595532, domain=142114528, errb={really_unlikely_name_to_have_accidentally_in_a_non_errb_structure = 42}, no_quit=1, no_fallback=1, depth=3) at /usr/local/src/xemacs-21.2-2000-02-24/src/specifier.c:2564 #15 0x80dc091 in update_face_cachel_data (cachel=0xbffff5f4, domain=142114528, face=137325984) at /usr/local/src/xemacs-21.2-2000-02-24/src/faces.c:1194 #16 0x80dcf68 in add_face_cachel (w=0x8787ee0, face=137325984) ---Type <return> to continue, or q <return> to quit--- at /usr/local/src/xemacs-21.2-2000-02-24/src/faces.c:1330 #17 0x80dd120 in get_builtin_face_cache_index (w=0x8787ee0, face=137325984) at /usr/local/src/xemacs-21.2-2000-02-24/src/faces.c:1361 #18 0x80dd1d7 in reset_face_cachels (w=0x8787ee0) at /usr/local/src/xemacs-21.2-2000-02-24/src/faces.c:1380 #19 0x81582bc in redisplay_window (window=142114528, skip_selected=0) at /usr/local/src/xemacs-21.2-2000-02-24/src/redisplay.c:5936 #20 0x81593dc in redisplay_frame (f=0x8744620, preemption_check=0) at /usr/local/src/xemacs-21.2-2000-02-24/src/redisplay.c:6410 #21 0x8159aee in redisplay_device (d=0x830ca78, automatic=1) at /usr/local/src/xemacs-21.2-2000-02-24/src/redisplay.c:6518 #22 0x8159f1e in redisplay_without_hooks () at /usr/local/src/xemacs-21.2-2000-02-24/src/redisplay.c:6577 #23 0x815a1ca in redisplay () at /usr/local/src/xemacs-21.2-2000-02-24/src/redisplay.c:6634 #24 0x80c6d0e in Fnext_event (event=141568704, prompt=137097236) at /usr/local/src/xemacs-21.2-2000-02-24/src/event-stream.c:2238 #25 0x806d4c4 in Fcommand_loop_1 () at /usr/local/src/xemacs-21.2-2000-02-24/src/cmdloop.c:566 #26 0x806d28f in command_loop_1 (dummy=137097236) at /usr/local/src/xemacs-21.2-2000-02-24/src/cmdloop.c:490 #27 0x808e1b2 in condition_case_1 (handlers=137097332, bfun=0x806d268 <command_loop_1>, barg=137097236, hfun=0x806ca94 <cmd_error>, harg=137097236) at /usr/local/src/xemacs-21.2-2000-02-24/src/eval.c:1629 #28 0x806cbbb in command_loop_3 () at /usr/local/src/xemacs-21.2-2000-02-24/src/cmdloop.c:252 #29 0x806cbe3 in command_loop_2 (dummy=137097236) at /usr/local/src/xemacs-21.2-2000-02-24/src/cmdloop.c:263 #30 0x808dd52 in internal_catch (tag=137169044, func=0x806cbd8 <command_loop_2>, arg=137097236, threw=0x0) at /usr/local/src/xemacs-21.2-2000-02-24/src/eval.c:1304 #31 0x806ce18 in initial_command_loop (load_me=137097236) at /usr/local/src/xemacs-21.2-2000-02-24/src/cmdloop.c:301 #32 0x808931d in xemacs_21_2_b31_i686_pc_linux (argc=1, argv=0xbffffbf4, envp=0xbffffbfc, restart=0) at /usr/local/src/xemacs-21.2-2000-02-24/src/emacs.c:1879 #33 0x8089fbf in main (argc=1, argv=0xbffffbf4, envp=0xbffffbfc) at /usr/local/src/xemacs-21.2-2000-02-24/src/emacs.c:2305 - vin

2 participants
1 comments

Re: Tabs problems 24 years, 2 months

Hrvoje Niksic

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > Hrvoje> What I'm talking about is the most basic *user* > Hrvoje> documentation, explaining how the buffer tabs are supposed > Hrvoje> to behave by default. > > At this point, all we need to say is (1) [mouse-1] on a tab goes to > that buffer OK. > and the doc-strings for (2) `buffers-tab-items' which says > > "This is the tab filter for the top-level buffers \"Buffers\" tab. > It dynamically creates a list of buffers to use as the contents of the > tab. ... This doesn't really sound user-friendly. Think about users who don't know Lisp (the vast majority) -- to them, the above docstring is Lisp-babble.

1 participants
0 comments

Re: Dynamic size spec for widgets 24 years, 2 months

Hrvoje Niksic

"Kirill 'Big K' Katsnelson" <kkm(a)dtmx.com> writes: > Some time ago, Olivier Galibert wrote... > > O "death to s/* m/*" G. > > configure if it ran on Windows would generate the same config.h > again and again. MS competitors, thanks Bill, supply exactly 0 > (zero) different compilers. Are you serious? Is there only a single C compiler on Windows?

3 participants
2 comments

Re: Dynamic size spec for widgets 24 years, 2 months

Hrvoje Niksic

"Kirill 'Big K' Katsnelson" <kkm(a)dtmx.com> writes: > Some time ago, Martin Buchholz wrote... > >1. Rename INLINE to INLINE_HEADER. > > > >2. Document the two approved ways of creating inline functions - in > > .h files, using INLINE_HEADER, and in .c files, using `static inline'. > > MSVC has `__inline' but no `inline'. This means that I'll have to put > > #define inline __inline > > in the s/ file. Is it clean? I think yes, just what do you think > about this. It sounds perfectly clean to me.

1 participants
0 comments

Re: Dynamic size spec for widgets 24 years, 2 months

Hrvoje Niksic

Martin Buchholz <martin(a)xemacs.org> writes: > - no inline support. > - gcc historic inline support > - C9x standard inline > - C++ standard inline [...] > Rule: if you have a static function, and you want to provide a > special hint for the compiler that this function _really_ should be > inlined (e.g if the function is known to be very frequently called), > I think you can currently do that _portably_ in the sources like > this: > > static inline .... I've been told that in C++ `inline' means `static inline'. Do all C++ compilers grok `static inline'? > As for renaming INLINE to INLINE_HEADER, that does seem like a safer > name, but I don't think it's worth making this global change now. I think it is. And it's especially important to *document* what it means. The annoying thing about the INLINE confusion is that it crops up time and again, by different people and with different code.

4 participants
5 comments

Re: Dynamic size spec for widgets 24 years, 2 months

Hrvoje Niksic

Martin Buchholz <martin(a)xemacs.org> writes: > >> Whatever you do, `inline' will never be more than a hint to the > >> compiler. > > Hrvoje> Whatever. Gcc for one has respected that hint whenever I > Hrvoje> tried it. > > There has recently been a flamewar on the gcc mailing list where > Linus got mad at the gcc people for no longer inlining functions > that had been inlined since the beginning of time. Yeah, we discussed it in Japan. Linus acted a loser because his code bogusly _depended_ on inlining, meaning that it actually broke if the functions were not inlined. We're not in the same situation here, not even in the same ballpark.

3 participants
2 comments

Re: [SUCCESS with kludges] Current CVS source under Red Hat 6.2 24 years, 2 months

Jan Vroonhof

"Kirill 'Big K' Katsnelson" <kkm(a)dtmx.com> writes: > $ cd / > $ ~/xemacs/src/xemacs -nw -q > Cannot open load file: /xemacs/lisp/auto-autoloads > (bails out) What happens if you do ~/xemacs/src/xemacs -nw -no-autoloads and what is the value of invocation-directory if it starts up? Jan

1 participants
0 comments

Re: [SUCCESS with kludges] Current CVS source under Red Hat 6.2 24 years, 2 months

Michael Sperber

>>>>> "Martin" == Martin Buchholz <martin(a)xemacs.org> writes: >>>>> "kkm" == Kirill 'Big K' Katsnelson <kkm(a)dtmx.com> writes: kkm> ./configure --with-xpm --with-file-coding --with-jpeg --with-png --with-xface kkm> Build went smoothly. XEmacs does not run under X, and when I kill it, the kkm> backtrace tops at (make-device 'x nil). What's wrong? kkm> Oh, I do not have xemacs-base. See below. kkm> With -nw, it reports in the warnings buffer: kkm> Initialization error while loading nil kkm> WTA: stringp, nil kkm> With -q, this error goes away. I do not have: ~/.em* ~/.xem* /usr/lib/xem* kkm> /usr/local/lib/xem* kkm> What could get loaded? Martin> ?? kkm> I cannot install packages. The XEmacs package finding logic will always be kkm> black magic to me. Wherever I put packages, XEmacs does not notice them, kkm> as per load-path. Where should I put them? Under Windows, the path kkm> ../../packages (or maybe /xemacs/packages) works perfectly, not under Unix. kkm> Help! "packages" for a directory name is wrong; "xemacs-packages" is right. This is documented in README.packages and Texinfo. Martin> I continue to claim our packages are a user install nightmare. These two are unrelated. (I feel like a broken record here, repeating this over and over.) Kirill, if renaming the directory doesn't work, you really need to state what you mean by "wherever". There's pretty extensive documentation in Texinfo on how the path startup logic works under "Startup paths". Also, you can start with "--debug-paths" and mail the output to the list, so I can look at it. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

2 participants
1 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 February 2000