bug-ncurses
[Top][All Lists]
Advanced

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

Re: ** Re: ncurses Ubuntu 64bit


From: Mike Aubury
Subject: Re: ** Re: ncurses Ubuntu 64bit
Date: Sun, 29 Sep 2013 11:58:59 +0100

Depending on the version of valgrind :

--track-origins=yes

might help...




On 28 September 2013 20:46, Thomas Dickey <address@hidden> wrote:
On Sat, Sep 28, 2013 at 02:28:01PM -0300, tjareson wrote:
> In my codeblocks IDE the application crashes exactly when this
> command is called:
> (so for instance when I type a character or digit)
>
> form_driver(screen_forms[screenid], ch);
>
> (which worked so far in a 32bit ubuntu environment)
>
> I've checked with valgrind (not sure if there would be any
> additional parameters necessary...)
> The result of valgrind I've pasted below. What I do not understand
> is, why valgrind is refering to /usr/lib/x86_64-linux-gnu/...
> In codeblocks I set the linker setting with a different path for all
> the ncurses related files, example:
> .../codeblocks/expen/ncurses/ncurses-5.9/lib/libformw.a

But it's linking against the shared libraries - valgrind is usually right in this regard.
Since there are no line-numbers for libformw, it's hard to guess whether your problem
is an overlooked bug in ncurses, or a bad parameter from your application.

When I do test-builds, using the whole ncurses sources, I've got it setup to use the
rpath feature for programs in the test-subdirectory.  That is pretty reliable.
(I don't use codeblocks or other IDEs for this...)

> ==16320== Memcheck, a memory error detector
> ==16320== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
> ==16320== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
> ==16320== Command: ./expen
> ==16320==
> ==16320== Invalid read of size 4
> ==16320==    at 0x5381772: form_driver (in /usr/lib/x86_64-linux-gnu/libformw.so.5.9)
> ==16320==    by 0x45B7C8: screen_runform(int, int) (screenio.cpp:1409)
> ==16320==    by 0x405923: userlogin(std::string) (auth.cpp:30)
> ==16320==    by 0x428118: main (main.cpp:92)
> ==16320==  Address 0x6fc2e14 is 4 bytes after a block of size 288 alloc'd
> ==16320==    at 0x4C29DB4: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==16320==    by 0x4816C5: _nc_makenew (in /home/tjareson/codeblocks/expen/bin/Debug/expen)
> ==16320==    by 0x481980: derwin (in /home/tjareson/codeblocks/expen/bin/Debug/expen)
> ==16320==    by 0x53806BC: _nc_Set_Current_Field (in /usr/lib/x86_64-linux-gnu/libformw.so.5.9)
> ==16320==    by 0x53824E5: post_form (in /usr/lib/x86_64-linux-gnu/libformw.so.5.9)
> ==16320==    by 0x450FFC: screen_loadform(std::string) (screenio.cpp:556)
> ==16320==    by 0x4058F8: userlogin(std::string) (auth.cpp:29)
> ==16320==    by 0x428118: main (main.cpp:92)
...
> >>Has anyone hints for me, where I should have a look into?
> >valgrind helps...
> >
> >If I had a simple program which demonstrates the problem, I'd plug it
> >into a build of ncurses as one of the test-programs, with debugging
> >enabled, and use valgrind to pinpoint the problem.
> >

--
Thomas E. Dickey <address@hidden>
http://invisible-island.net
ftp://invisible-island.net

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAlJHMhgACgkQcCNT4PfkjttX5wCguXiThKgf4cAEMl0SjvGD5Y4q
JUoAoKy7S/CphZeV80dC/8A4VXAD2Ef+
=vWhk
-----END PGP SIGNATURE-----

_______________________________________________
Bug-ncurses mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/bug-ncurses



reply via email to

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