[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LYNX-DEV More on my SPARC/Solaris 2.4/Lynx development version crash
Re: LYNX-DEV More on my SPARC/Solaris 2.4/Lynx development version crashes
Tue, 14 Oct 1997 13:45:14 -0500 (CDT)
Try again with 2.7.1ac-0.82. I made some tweaks that might be
relevant, although I doubt it.
I don't really understand the innards of the character style code,
and have no inclination now to try to figure them out. But let me
assure you that I am able to run the color-style code on sol.slcc.edu
without big problems. Display glitches - yes; crashes - no.
The --enable-find-leaks stuff (I have finally tried it, it works
very nicely when it does, and I have made some additions) isn't useful
if you never get the program beyond the startup phase, so disable it.
It might even add addititional problems.
On Mon, 13 Oct 1997, Larry W. Virden, x2487 wrote:
> Okay, over the weekend I reported problems with crashs in lynx 0.78. I
> have upgraded to 0.81. I compile on a SPARC/Solaris2.4/Sun compiler/ncurses.
> When I compile without the --enable-color-style flag,
> lynx works fine.
> When I compile with the --enable-color-style flag,but
> do not have a stylesheet installed, I get incorrect (in my estimation)
> behavior for expert mode status messages (urls, etc.) but the software
> at least works. The incorrect behavior is as I mentioned over the weekend
> that the status messages write overtop of each other without blanking out
> the previous value - resulting in frequent unreadable status lines when
> a short URL or message appears after a longer one.
I also get a strange statusline with e.g. -lss=/dev/null, althogh it
is bad in a different way. But these are glitches. What happens if
you use a mini lss file with just two lines, for "status" and "alert" ?
> When I run this color style enabled version with a stylesheet installed, I get
> a core dump. Here is the trace file and following it I will include a stack
> trace from the dump.
> Lynx Trace Log
Why does your mail contain embedded 0xff chars? (or as they arrived here,
probably due to a bit-stripping MTA, 0x7f.)
Are there other things broken with your system in subtle ways?
> CSS:Reading styles from file: /projects/sprs_lwv/lib/lynx/styles/lynx.lss
Here for example:
> SETTING SUFFIX '.rtx' t
Larry, you're well known on this list as the guy with the bloated mime.types
and mailcap files :) :) -
for example, the following is garbage:
> SETTING SUFFIX '..rm' to 'audio/x-pn-realaudio'
> SETTING SUFFIX '..ra' to 'audio/x-pn-realaudio'
> SETTING SUFFIX '..ram' to 'audio/x-pn-realaudio'
> SETTING SUFFIX '.\' to 'audio/x-pn-realaudio'
> SETTING SUFFIX '.\' to 'type=audio/x-pn-realaudio'
> SETTING SUFFIX '.\' to 'desc="realaudio"'
I have made some minor changes to the parsing of the .types files
recently, you may want to check whether that has changed anything in
the "SETTING SUFFIX" trace output for you, but I doubt it.
Anyway, I don't see *how* this could be related to the other problems,
but your big mailcap/mime.types file *are* something where your
situation is different from other people's, so try to set them all to
/dev/null and see whether that changes anything.
> $ dbx lynx core
> Reading symbolic information for lynx
> core file header read successfully
> Reading symbolic information for rtld /usr/lib/ld.so.1
> Reading symbolic information for libncurses.so.4
> Reading symbolic information for libnsl.so.1
> Reading symbolic information for libsocket.so.1
> Reading symbolic information for libc.so.1
> Reading symbolic information for libdl.so.1
> Reading symbolic information for libintl.so.1
> Reading symbolic information for libmp.so.1
> Reading symbolic information for libw.so.1
> program terminated by signal BUS (invalid address alignment)
> Current function is LYLeakMalloc
> 198 void *vp_malloc = (void *)malloc(st_bytes);
> (dbx 1) where
>  t_delete(0x408858, 0xffffffff, 0xef655bf8, 0x408868, 0x408858,
> 0xef655c84), at 0xef60be28
>  _malloc_unlocked(0x30, 0x0, 0x408858, 0x40, 0x408868, 0x408858), at
>  malloc(0x2c, 0x0, 0xffffffff, 0x0, 0x0, 0x42acc9), at 0xef60b368
> => LYLeakMalloc(st_bytes = 44U, cp_File = 0x2729d8
> "../../Library/Implementation/HTString.c", ssi_Line = 82), line 198 in
>  HTSACopy(dest = 0x2e6f8c, src = 0x406380
> "http://homepage/home/lwv26/.parms/home.html"), line 82 in "HTString.c"
>  mainloop(), line 218 in "LYMainLoop.c"
>  main(argc = 2, argv = 0xefffe6c4), line 1694 in "LYMain.c"
An "invalid address alignment" caused within the innards of the
system's (C library's ?) implementation of malloc looks weird to me.
Could also be that the Lynx code is writing to unallocated memory, but
I have no indication that it does, or where it happens, and if it's
somewhere in the innards of the style code I don't wanna look for it.
But are you sure your system is sane? Is there an alternative
libmalloc or libgnumalloc or whatever you could try to link with?
; To UNSUBSCRIBE: Send a mail message to address@hidden
; with "unsubscribe lynx-dev" (without the
; quotation marks) on a line by itself.