Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: Help building proper debug version libcurl/7.29.0
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 1 Nov 2023 23:11:29 +0100 (CET)
On Wed, 1 Nov 2023, Ali Ahmed via curl-library wrote:
> I'm trying to build a debug version of libcurl to debug a seg fault issue.
> The version of libcurl on the faulting system is:
> libcurl version libcurl/7.29.0 NSS/3.53.1 zlib/1.2.7 libidn/1.28
> libssh2/1.8.0
First: I assume that you want to reproduce a crash in this ancient curl
version that you installed from somewhere. Like a Redhat or CentOS
installation. Then you should take into account that they have patched that
curl version quite a lot so the 7.29.0 you've been using is probably not
exactly the 7.29.0 you get from the curl git repository.
Then: what is the desired outcome of this exercise? I presume you ideally want
to find the bug, fix it, rebuild a new version and then use this fixed version
in your system? But if you can do this, is it not then perhaps smarter and
faster to just try a much newer libcurl version first to see if the bug is not
perhaps already fixed?
> I've built a version of libcurl with debug enabled via ./configure; however
> whenever I attempt to add the debug symbols to gdb the wrong offsets are
> used and the stack trace changes completely while debugging the core file
Unless you're doing some special cross-compile or something, then I don't
quite see why this causes problems. I've done './configure --enable-debug'
builds for curl since forever, and then I can just gdb the results without
having to explicitly load any debug symbols and I have never experienced them
having wrong offset. I can't even understand how they can end up wrong...
> Q1) Can anyone tell me the options to pass into the configure script to
> match the version on the faulting system?
Compare the configure summary with what you want to build and make sure it
detects all the libraries you want to use.
> Q2) Do I need to make sure the NSS, zlib, libidn, libssh2 libraries on the
> debug build machine match the ones found on the faulting machine?
Yes. Since your crash is deep inside NSS it seems critical that you have the
same NSS version at least. The other libraries might have a lessser
importance. Curiously though, your NSS version (3.53.1) was released in
2020-06-16 while your libcurl is from 2013-02-06.
Date: Wed, 1 Nov 2023 23:11:29 +0100 (CET)
On Wed, 1 Nov 2023, Ali Ahmed via curl-library wrote:
> I'm trying to build a debug version of libcurl to debug a seg fault issue.
> The version of libcurl on the faulting system is:
> libcurl version libcurl/7.29.0 NSS/3.53.1 zlib/1.2.7 libidn/1.28
> libssh2/1.8.0
First: I assume that you want to reproduce a crash in this ancient curl
version that you installed from somewhere. Like a Redhat or CentOS
installation. Then you should take into account that they have patched that
curl version quite a lot so the 7.29.0 you've been using is probably not
exactly the 7.29.0 you get from the curl git repository.
Then: what is the desired outcome of this exercise? I presume you ideally want
to find the bug, fix it, rebuild a new version and then use this fixed version
in your system? But if you can do this, is it not then perhaps smarter and
faster to just try a much newer libcurl version first to see if the bug is not
perhaps already fixed?
> I've built a version of libcurl with debug enabled via ./configure; however
> whenever I attempt to add the debug symbols to gdb the wrong offsets are
> used and the stack trace changes completely while debugging the core file
Unless you're doing some special cross-compile or something, then I don't
quite see why this causes problems. I've done './configure --enable-debug'
builds for curl since forever, and then I can just gdb the results without
having to explicitly load any debug symbols and I have never experienced them
having wrong offset. I can't even understand how they can end up wrong...
> Q1) Can anyone tell me the options to pass into the configure script to
> match the version on the faulting system?
Compare the configure summary with what you want to build and make sure it
detects all the libraries you want to use.
> Q2) Do I need to make sure the NSS, zlib, libidn, libssh2 libraries on the
> debug build machine match the ones found on the faulting machine?
Yes. Since your crash is deep inside NSS it seems critical that you have the
same NSS version at least. The other libraries might have a lessser
importance. Curiously though, your NSS version (3.53.1) was released in
2020-06-16 while your libcurl is from 2013-02-06.
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-11-01