Re: ncurses Ubuntu 64bit

[tjareson]

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

==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)
==16320==
==16320== Invalid read of size 8
==16320==    at 0x537DD11: ??? (in 
/usr/lib/x86_64-linux-gnu/libformw.so.5.9)
==16320==    by 0x537ECD0: ??? (in 
/usr/lib/x86_64-linux-gnu/libformw.so.5.9)
==16320==    by 0x5381786: 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 0x700000000 is not stack'd, malloc'd or (recently) free'd
==16320==
==16320==
==16320== Process terminating with default action of signal 11 (SIGSEGV)
==16320==  Access not within mapped region at address 0x700000000
==16320==    at 0x537DD11: ??? (in 
/usr/lib/x86_64-linux-gnu/libformw.so.5.9)
==16320==    by 0x537ECD0: ??? (in 
/usr/lib/x86_64-linux-gnu/libformw.so.5.9)
==16320==    by 0x5381786: 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==  If you believe this happened as a result of a stack
==16320==  overflow in your program's main thread (unlikely but
==16320==  possible), you can try to increase the size of the
==16320==  main thread stack using the --main-stacksize= flag.
==16320==  The main thread stack size used in this run was 8388608.
==16320==
==16320== HEAP SUMMARY:
==16320==     in use at exit: 1,119,347 bytes in 537 blocks
==16320==   total heap usage: 5,549 allocs, 5,012 frees, 1,764,266 bytes 
allocated
==16320==
==16320== LEAK SUMMARY:
==16320==    definitely lost: 0 bytes in 0 blocks
==16320==    indirectly lost: 0 bytes in 0 blocks



Am 27.09.2013 20:06, schrieb Thomas Dickey:
> On Fri, Sep 27, 2013 at 07:30:44PM -0300, tjareson wrote:
> > Hello,
> >
> > are there any special configurations or settings to consider, when
> > compiling ncurses and forms in a 64 bit environment? Or any known
> > pitfalls?
> >
> > I've tried to compile an application which uses forms (also using
> > wide characters) which compiles and runs without any problem in an
> > Ubuntu 32bit evironment.
> >
> > When I compile and run exactly the same setup (ncurses 5.9) on the
> > Ubuntu 64bit environment, the application causes a segmentation
> > fault, whenever a character is typed into a forms field.
> > When I switch between fields with cursor keys everything work, only
> > when the formsdriver get called with a character the thing crashes.
> >
> > 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.