Created attachment 434610 [details] emerge --info + bash history While working on bug #579580 I ran into a problem which is very likely either gnunet-gtk or gentoo gcc or glibc caused. The attached logs and outputs describe all data I have gathered in the test VM, if something is missing I can provide it later on. (Cross reference: https://bugs.gentoo.org/show_bug.cgi?id=579580)
Created attachment 434612 [details] gnunet-gtk config.log
Created attachment 434614 [details] gnunet-gtk build.log
Created attachment 434616 [details] gnunet config.log
Created attachment 434618 [details] gnunet build.log
Created attachment 434620 [details] valgring + gdb on gnunet-gtk
The 2 ebuilds I work on sit in the overlay named "testing", which can be cloned via the ways described at http://c.n0.is/. You'd furthermore need to clone the "youbroketheinternet-overlay" for the dependency "gnurl". The VM I worked in is a vanilla gcc amd64 system.
just glancing at the logs implies it's not a toolchain problem, so you'll want to debug the app a bit more #3 0x00007ffff7970b3a in GNUNET_xstrdup_ (str=0x0, filename=filename@entry=0x7ffff79bfc94 "program.c", linenumber=linenumber@entry=224) at common_allocation.c:276 you probably shouldn't be doing strdup(NULL)
Thanks for your input. Do you mean to debug gnunet at its core, upstream, or debug the build/how it builds on Gentoo?
(In reply to Nils Gillmann (ng0) from comment #8) > Thanks for your input. > Do you mean to debug gnunet at its core, upstream, or debug the build/how it > builds on Gentoo? To clarify, I'd like some explanation, as I had it working and running at some point in the git history but for what I have now (eapi6) I can't go back to there.
Created attachment 435080 [details] egrep -nr "strdup" Output of egrep -nr "strdup" in the root of /svn/ of gnunet. If you mean that I should patch around this: at the moment I don't have enough knowledge to do this. Sources to read up on (including similar solutions/problems) would be good if they exist, else I will search for them myself. I see many results in my portage checkout, but if someone with more knowledge on this could give me input before I go on it would be highly appreciated.
I am working on this now with upstream, trying out some solutions.
(In reply to Nils Gillmann (ng0) from comment #8) you've got the backtrace already with gdb, so you know the exact files to look at. if the optimization is getting in the way, try forcing -O0 to see if it's more clear how the bad call is coming about. i would focus on that via gdb rather than worry about valgrind.
Created attachment 435120 [details] gdb gnunet-gtk (after patch) after the patch schanzen supplied and I adjusted to Gentoo build system, the error changed.
Created attachment 435122 [details] valgrind gnunet-gtk (after patch) same. (valgrind output because gdb was connected to valgrind)
unless you're super comfortable with valgrind, i would get it out of the equation entirely. focus on running the program directly through gdb.
Created attachment 435236 [details] build log (gnunet-gtk) this is the new build.log after an updated patch.
Created attachment 435238 [details] config.log (gnunet-gtk) this is the config.log after an updated patch
Created attachment 435240 [details] environment this is the environment file of gnunet-gtk after an updated patch
Created attachment 435242 [details] gdb gnunet-gtk (updated patch) gdb output of 2016-05-24 14:05 UTC, as seen after patch version 2.
that shows some code still trying to strdup(NULL). if you're at the level of building & debugging the code, you probably want to just work directly with upstream.
resolved with gnunet developers in gnunet-gtk Revision 37201.
