I tested the new 0.93 Sol7-xlib version and whilst attempting to search the bugzilla data base via http://bugzilla.mozilla.org/ i found that this version does not properly echo input. Input does, however, show up in the window where mozilla is started. The following shows what happened: %[503] /usr/local/mozilla/mozilla /usr/local/mozilla/run-mozilla.sh /usr/local/mozilla/mozilla-bin MOZILLA_FIVE_HOME=/usr/local/mozilla LD_LIBRARY_PATH=/usr/local/mozilla:/usr/local/mozilla/plugins:/usr/local/adabas/lib:/usr/local/pgsql/lib:/usr/openwin/lib:/usr/dt/lib:/usr/local/lib LIBRARY_PATH=/usr/local/mozilla:/usr/local/mozilla/components SHLIB_PATH=/usr/local/mozilla LIBPATH=/usr/local/mozilla ADDON_PATH=/usr/local/mozilla MOZ_PROGRAM=/usr/local/mozilla/mozilla-bin MOZ_TOOLKIT= moz_debug=0 moz_debugger= registerSelf for remoteControl >>>>>>>>>>>> chatzilla-service loaded*** Registering -chat handler. *** Registering x-application-irc handler. *** Registering irc protocol handler. *** Registering -venkman handler. An error occurred reading the startup configuration file. Please contact your administrator. line 62: unterminated string literal. user_pref("mail.signa NS_ProcessTimeouts() lives! xlibxlibxlib xlib x BYE BYE BYE BYE %

-> Roland.Mainz@informatik.med.uni-giessen.de I don't understand what you mean by 'echo input'? Second question: the error line 62: unterminated string literal. user_pref("mail.signa means that on of the preferences JS files is corrupt (e.g., grep for 'user_pref("mail.signa' in <install_dir>/defaults/pref and see what is wrong with that file. However, even when one of those files is corrupt, you should be able to keep running. (Which makes me wonder what else might not be right about the tarball and/or its state on your machine).

I simply cnp the output from the session. I am aware of the other errors but do not feel they are significant wrt improper handling of form fields. I will certainly check. I pulled the image from mozilla release downloads. THe problem that I am bringing to your attention is as follows: http://bugzilla.mozilla.org/ presents a form. This take the form of a text box on near the left margin of the display. Normally when one enters data into one of these fields the input is echoed back. In the case of the current release characters are not echoed as shown by the line "xlibxlibxlib" in the output. Once I figured out that there was no echo (the next line in the output) I got my list of Xlib bugs. I uspect that the chat stuff and other errors resulted from the fact that I was xhosting on a 2.6 machine from a 2.7 box. Since this worked, I became very happy ;-) and ignored these. If at all possible I would like to get a working .mozconfig for 0.93xlib.

CC:ing myself and some xlib-toolkit folks...

html form controls

I am having difficulty building mozilla-0.93 under Solaris 2.6. What I find is that the build always fails in mozilla/content/html/content/src/ on nsHTMLDListElement.cpp. I only bring this up because of the Change of the Component of this bug. I do not know whether or not this is related to the problem but thought it worth mentioning.

Wanna post the exact error message, please ?

The original error is no longer in the cache. However a similar error has occured. Here is the message: c++ -o BooleanFunctionCall.o -c -DOSTYPE=\"SunOS5\" -DOSARCH=\"SunOS\" -DOJI -I../../../../dist/include -I../../../../dist/include -I/backup/mozilla/dist/include/nspr -I./../base -I./../xml -I./../xml/dom -I./../xml/util -I./../xslt -I./../xslt/util -I./../xslt/functions -I. -I/usr/openwin/include -fPIC -I/usr/openwin/include -fno-rtti -fno-exceptions -pedantic -Wno-long-long -pthreads -O -DNDEBUG -DTRIMMED -I/usr/openwin/include -DMOZILLA_CLIENT -include ../../../../config-defs.h -Wp,-MD,.deps/BooleanFunctionCall.pp BooleanFunctionCall.cpp gmake[5]: *** [BooleanFunctionCall.o] Bus Error (core dumped) gmake[5]: Leaving directory `/backup/mozilla/extensions/transformiix/source/xpath' gmake[4]: *** [install] Error 2 gmake[4]: Leaving directory `/backup/mozilla/extensions/transformiix/source' gmake[3]: *** [install] Error 2 gmake[3]: Leaving directory `/backup/mozilla/extensions/transformiix' gmake[2]: *** [install] Error 2 gmake[2]: Leaving directory `/backup/mozilla/extensions' gmake[1]: *** [install] Error 2 gmake[1]: Leaving directory `/backup/mozilla' gmake: *** [build] Error 2 gcc-2.95.3 (c++) gmake-3.79.1 I do suspect that gcc is the source of the problem but have not been able to confirm.

Find the core file (should be in `/backup/mozilla/extensions/transformiix/source/xpath') and run "/usr/bin/file core" - this should give you the program which crashed. Please extract a stack trace from the core dump (via GDB - or use /usr/proc/bin/pstack in Solaris >= 2.8) and post it here...

Per Roland's request: #[211] file core core: ELF 32-bit MSB core file SPARC Version 1, from 'c++' (COnfirms my suspicions) The OS is Solaris 2.6 and doesn't have the luxeries of GDB or pstack. However, I do have dbx and adb. What follow's is the output of an adb script I concocted many years ago to do crash analysis. Should be good enough. I will follow with dbx output if it works. ADB Stuff: ** Calltrace ** ----------------- l0 l1 l2 l3 l4 l5 l6 l7 i0 i1 i2 i3 i4 i5 i6 i7 0xefffefb8: 0 c7d 38e30 64580 f00a8954 20 40 40 37bc8 0 22810 0 e00b2e6c 0 38eb0 2 0xefffefb8: 0 0xc7d 0x38e30 0x64580 0xf00a8954 0x20 0x40 0x40 0x37bc8 0 0x22810 0 0xe00b2e6c 0 0x38eb0 2 DBX Stuff: %[502] dbx /usr/local/bin/c++ core Reading symbolic information for /usr/local/bin/c++ core file header read successfully Reading symbolic information for rtld /usr/lib/ld.so.1 Reading symbolic information for /usr/lib/libc.so.1 Reading symbolic information for /usr/lib/libdl.so.1 program terminated by signal BUS (invalid address alignment) dbx: core file read error: address 0x20000 not in data space dbx: attempt to read stack failed - bad frame pointer (dbx) where =>[1] mkstemps(0x37bc8, 0x0, 0x22810, 0x0, 0xe00b2e6c, 0x0), at 0x1c89c [2] 0x2(0x0, 0x1ffd8, 0x1ffd0, 0x0, 0x0, 0x0), at 0x1 dbx: core file read error: address 0x20000 not in data space dbx: attempt to read stack failed - bad frame pointer Well I never! I have just found a packaged GDB for 2.6 and installed it. Here is the output: (gdb) backtrace #0 0x1c89c in mkstemps (template=0x37bc8 ".s", suffix_len=0) at ../../libiberty/mkstemps.c:115 #1 0xa in ?? () #2 0x1ffd8 in _lib_version () #3 0x6e6c7942 in ?? () Cannot access memory at address 0x30303032. The build completed whilst I was preparing the above. I have now tested the build and I'm back to my original problem of no remote handling. ( See [Bug 89784] 0.92 built with --enable-toolkit=xlib will not display remotely) GDB Stuff:

(reporter is no longer reachable)

Xlib port has been removed from trunk (bug 326152) -> WONTFIX