[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Lynx-dev] glibc-detected "double free or corruption bug" in lynx (2

From: Thomas Dickey
Subject: Re: [Lynx-dev] glibc-detected "double free or corruption bug" in lynx (2.8.8dev.14)
Date: Fri, 25 Jan 2013 16:07:07 -0500
User-agent: Mutt/1.5.20 (2009-06-14)

On Fri, Jan 25, 2013 at 10:29:40AM +0100, dREPLACEeLETTEReEjBYeLETTEReAatGMA 
ILcom wrote:
> Thank you for you answer.
> a) I used the stock lynx compiled for Linux Sabayon, available here:

thanks - I'll investigate this and see if I can reproduce the problem.

> b) Can you explain to me how to modify this script

I'd add the "--enable-debug" option to the configure options.
Then once it is built, the file before installing (which strips
the executable) is something that you can use valgrind with.
If there are no symbols, valgrind is not very useful.

The "file" program shows "stripped" when there are no symbols:

/usr/bin/lynx-dev: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), 
dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped

I use valgrind on various programs using a script like this:

rm -f vgcore*.*

OPTS="-v \
        --num-callers=10 \
        --error-limit=no \
        --show-reachable=yes \
        --leak-resolution=high \
        --leak-check=yes \

valgrind $OPTS \
        --log-fd=2 \
        "$@" 2>valgrind.log

So... (calling that "run-valgrind", I just do
        run-valgrind ./lynx

and look in valgrind.log for problems.  valgrind of course is a program
that you may/may not already have installed.

> Are you able to use a coredump file if I provide one ? If you answer

usually not - the libraries referred to wouldn't be the same.
But running gdb on your system, you can get whatever is useful
from it by a traceback (showing the functions called).  If it
is from a non-stripped executable, we can see line-numbers and

gdb /usr/bin/lynx core
...shows the traceback

> yes, I will from know use lynx so that it dumps core next time I have
> a bug to report.
> The bug happened on a lynx process started 07 Jan 2013. The system has
> been updated afterwards, on 09/01/2013, upgrading to
> www-client/lynx-2.8.8_pre15 (from ..._pre14), and to
> net-dns/libidn-1.26 (from ..-1.25). The bug happened on Monday, after

That would be "dev", not "pre":

2012-11-18 (2.8.8dev.15)
2012-08-22 (2.8.8dev.14)
2012-08-15 (2.8.8dev.13)
2012-02-22 (2.8.8dev.12)
2012-02-19 (2.8.8dev.11)
2012-02-12 (2.8.8dev.10)
2011-06-12 (2.8.8dev.9)
2011-01-10 (2.8.8dev.8)
2010-12-11 (2.8.8dev.7)
2010-10-04 (2.8.8dev.6)
2010-08-25 (2.8.8dev.5)
2010-06-21 (2.8.8dev.4)
2010-04-25 (2.8.8dev.3)
2009-11-25 (2.8.8dev.2)
2009-08-28 (2.8.8dev.1)

I might mark a "pre" after dev.16 (at the moment I'm working on a large
change for luit, and have in-progress changes for lynx and vile - things
take time...).

Thomas E. Dickey <address@hidden>

Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]