Arvind, thanks for your report. Can you give us a recipe to reproduce
your crash? I use XEmacs fairly extensively on my Solaris boxes at
work, and it works reliably. (I generally build with the Sun C
compiler, but I do on occasion build with gcc, currently version
3.2.2, I believe.)
Arvind Devarajan <arvind.sankruthi(a)oracle.com> writes:
/usr/dt/lib:/usr/openwin/lib:/home2/gcc/bin/../lib/gcc-lib/sparc-sun-solaris2.6/3.1/../../..:/home2/gcc//lib/gcc-lib/sparc-sun-solaris2.6/3.1/../../..
Unrelated to your problem, but aren't those last 2 directories in your
runtime library path the same?
Operating system description file: `s/sol2.h'
Machine description file: `m/sparc.h'
Compiler: gcc -g -O3 -Wall -Wno-switch
-Winline -Wmissing-prototypes -Wsign-compare -Wshadow -Wpointer-arith
Relocating allocator for buffers: yes
GNU version of malloc: yes
Window System:
Compiling in support for the X window system:
- X Windows headers location: /usr/dt/include
/usr/openwin/include
- X Windows libraries location: /usr/dt/lib
/usr/openwin/lib
- Handling WM_COMMAND properly.
Using Lucid menubars.
Using Lucid scrollbars.
Using Motif dialog boxes.
Using Motif native widgets.
TTY:
Compiling in support for ncurses.
Images:
Compiling in support for GIF images (builtin).
Compiling in support for XPM images.
Compiling in support for PNG images.
Compiling in support for JPEG images.
Sound:
Databases:
Compiling in support for Berkeley database.
Compiling in support for DBM.
Internationalization:
Mail:
Compiling in support for "dot-locking" mail spool file locking method.
Other Features:
Inhibiting IPv6 canonicalization at startup.
Compiling in support for ToolTalk.
Compiling in support for dynamic shared object modules.
/*Call stack obtained from gdb:*/
#0 0xef00a5f0 in ?? ()
#1 0xeefb973c in ?? ()
#2 0xef6cd97c in ?? ()
#3 0xef68041c in ?? ()
#4 0xef6cda48 in ?? ()
#5 0xef39f9a4 in ?? ()
#6 0xef3a8208 in ?? ()
#7 0xef3a8420 in ?? ()
#8 0xef3a8630 in ?? ()
#9 0x17b08c in MenuProcedureEntry ()
#10 0x6a7a8 in Fscroll_left ()
#11 0x61710 in output_display_line ()
#12 0x7cdf0 in x_any_window_to_frame ()
#13 0x7fff8 in x_show_gc_cursor ()
#14 0x558b0 in create_text_block ()
#15 0x5542c in add_glyph_rune ()
#16 0x7ff24 in Fx_set_scrollbar_pointer ()
#17 0x598b4 in regenerate_window_incrementally ()
#18 0x7ec70 in x_initialize_frame_size ()
#19 0xafd6c in Fexpand_file_name ()
#20 0xabfbc in buffer_insert_c_string_1 ()
#21 0x5fe64 in vars_of_redisplay ()
#22 0x7dc74 in init_x_parm_symbols ()
---Type <return> to continue, or q <return> to quit---
#23 0x6031c in sync_rune_structs ()
#24 0x7db38 in init_x_parm_symbols ()
#25 0x5faf0 in Fforce_cursor_redisplay ()
#26 0x7b2a8 in x_generate_shadow_pixels ()
#27 0x7bac0 in x_redraw_exposed_area ()
This backtrace doesn't help much. Can you build an XEmacs with
debugging enabled (ie configured --debug)? A recipe that reliably
reproduces your crash from a -vanilla XEmacs would be more likely to
get investigated.
Thanks,
Vin