Re: LYNX-DEV More on my SPARC/Solaris 2.4/Lynx development version crashes

[Larry W. Virden, x2487]

From: Klaus Weide <address@hidden>

> Larry,
> 
>  Try again with 2.7.1ac-0.82.  I made some tweaks that might be
> relevant, although I doubt it.

I am downloading the patch now.

> 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" ?

I don't know - I'm not familar enough with the lss format to know how to
do just the two lines.  Sorry.

> Why does your mail contain embedded 0xff chars?  (or as they arrived here,
> probably due to a bit-stripping MTA, 0x7f.)

Because they are in the trace file.  If you like, I would be happy to uuencode
the file.  As for why they are in the trace file - I've no idea.

> Are there other things broken with your system in subtle ways?

Got me - everything else seems to be working.  And if I don't turn on
the character style stuff, the new lynx works fine...

> > 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 :) :) -

Yes sigh.  I do have lots of stuff in there - comes with the pain of trying
to maintain one mailcap / mime type file for all my email/web browsing/other
tool using purposes.  Seems counter productive to me to try to maintain 
a dozen different ones just because tools can't seem to get the hang of it.



> 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"'

Could be - unfortunate, Netscape Helper decides to put all sorts of trash
in my mimetypes file without telling me!  It's not _always_ my fault you
know!


> 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                                                         
> >   [1] t_delete(0x408858, 0xffffffff, 0xef655bf8, 0x408868, 0x408858, 
> > 0xef655c84), at 0xef60be28
> >   [2] _malloc_unlocked(0x30, 0x0, 0x408858, 0x40, 0x408868, 0x408858), at 
> > 0xef60b520
> >   [3] malloc(0x2c, 0x0, 0xffffffff, 0x0, 0x0, 0x42acc9), at 0xef60b368
> > =>[4] LYLeakMalloc(st_bytes = 44U, cp_File = 0x2729d8 
> > "../../Library/Implementation/HTString.c", ssi_Line = 82), line 198 in 
> > "LYLeaks.c"
> >   [5] HTSACopy(dest = 0x2e6f8c, src = 0x406380 
> > "http://homepage/home/lwv26/.parms/home.html";), line 82 in "HTString.c"
> >   [6] mainloop(), line 218 in "LYMainLoop.c"
> >   [7] 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?

I'm using, as far as I am aware, Sun's allocation code -there may be
other mallocs out there, but since my employer has a support contract
with Sun, we try to stick with the vendor as much as possible.  If
lynx is using it's own malloc, then I of course would be using it.
-- 
Larry W. Virden                 INET: address@hidden
<URL:http://www.teraform.com/%7Elvirden/> <*> O- "We are all Kosh."
Unless explicitly stated to the contrary, nothing in this posting should 
be construed as representing my employer's opinions.
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;