Bug 332917 - Crash in libcurl when checking metadata
Summary: Crash in libcurl when checking metadata
Status: RESOLVED FIXED
: 332105 333390 (view as bug list)
Alias: None
Product: openSUSE 10.3
Classification: openSUSE
Component: libzypp (show other bugs)
Version: Final
Hardware: x86-64 openSUSE 10.3
: P5 - None : Critical (vote)
Target Milestone: ---
Assignee: Michal Marek
QA Contact: Duncan Mac-Vicar
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-10-11 12:15 UTC by Eskil Bylund
Modified: 2008-10-20 08:49 UTC (History)
9 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
Full backtrace (42.63 KB, text/x-log)
2007-10-11 12:17 UTC, Eskil Bylund
Details
Valgrind and strace logs (512.11 KB, application/x-bzip2)
2007-10-12 09:31 UTC, Eskil Bylund
Details
checking mirrors for FTP redirects (6.10 KB, text/plain)
2007-10-23 19:00 UTC, Peter Poeml
Details
Testcase (1.11 KB, text/plain)
2008-04-25 12:28 UTC, Andreas Schwab
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eskil Bylund 2007-10-11 12:15:13 UTC
Probably related to #332105, but since the backtrace is somewhat different I'm creating a new report. Crashes zypper and the package manager in yast every time.

# rpm -q zypper libzypp curl
zypper-0.8.23-7.x86_64
libzypp-3.26.2-2.x86_64
curl-7.16.4-15.x86_64

# zypper update
*** glibc detected *** zypper: free(): invalid pointer: 0x00002b9d9926b192 ***
======= Backtrace: =========
/lib64/libc.so.6[0x2b9d97b6021d]
/lib64/libc.so.6(cfree+0x76)[0x2b9d97b61f76]
/usr/lib64/libcurl.so.4[0x2b9d9924bacf]
/usr/lib64/libcurl.so.4[0x2b9d9924efad]
/usr/lib64/libcurl.so.4[0x2b9d9924f47e]
/usr/lib64/libcurl.so.4[0x2b9d992509ce]
/usr/lib64/libcurl.so.4[0x2b9d9925334f]
/usr/lib64/libcurl.so.4[0x2b9d99260206]
/usr/lib64/libzypp.so.324(_ZNK4zypp5media9MediaCurl13doGetFileCopyERKNS_10filesystem8PathnameES5_RNS_8callback10SendReportINS0_22DownloadProgressReportEEE+0xf70)[0x2b9d9696c7b0]
/usr/lib64/libzypp.so.324(_ZNK4zypp5media9MediaCurl11getFileCopyERKNS_10filesystem8PathnameES5_+0x178)[0x2b9d9696a728]
/usr/lib64/libzypp.so.324(_ZNK4zypp5media9MediaCurl7getFileERKNS_10filesystem8PathnameE+0xf3)[0x2b9d96968753]
/usr/lib64/libzypp.so.324(_ZNK4zypp5media12MediaHandler11provideFileENS_10filesystem8PathnameE+0x173)[0x2b9d96947433]
/usr/lib64/libzypp.so.324(_ZNK4zypp5media11MediaAccess11provideFileERKNS_10filesystem8PathnameEbb+0x76)[0x2b9d9693f646]
/usr/lib64/libzypp.so.324(_ZNK4zypp5media12MediaManager11provideFileEjRKNS_10filesystem8PathnameEbb+0x66)[0x2b9d96986356]
/usr/lib64/libzypp.so.324(_ZN4zypp14MediaSetAccess19provideFileInternalERKNS_10filesystem8PathnameEjbb+0x19c)[0x2b9d96b75a4c]
/usr/lib64/libzypp.so.324(_ZN4zypp14MediaSetAccess11provideFileERKNS_10filesystem8PathnameEj+0xf)[0x2b9d96b76baf]
/usr/lib64/libzypp.so.324(_ZN4zypp4repo8susetags10Downloader6statusERNS_14MediaSetAccessE+0xb2)[0x2b9d969e3e12]
/usr/lib64/libzypp.so.324(_ZN4zypp11RepoManager24checkIfToRefreshMetadataERKNS_8RepoInfoERKNS_3UrlENS0_24RawMetadataRefreshPolicyE+0x694)[0x2b9d96b91134]
zypper[0x4503c9]
zypper[0x4528f9]
zypper(_Z11one_commandiPPc+0x575d)[0x42e9ad]
zypper(_Z16safe_one_commandiPPc+0x20)[0x42eec0]
zypper(main+0x11f)[0x42ff3f]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x2b9d97b0fb54]
zypper(__gxx_personality_v0+0x319)[0x426139]
Comment 1 Eskil Bylund 2007-10-11 12:17:44 UTC
Created attachment 177672 [details]
Full backtrace
Comment 2 Michal Marek 2007-10-11 13:02:31 UTC
Could please you also run

1) valgrind --log-file=zypper-vg-log /usr/bin/zypper update
2) strace -s 4096 -o zypper-strace-log /usr/bin/zypper update

and attach the logs (compressed if needed)? Thanks!

Jano: I'll look at the curl side to see if the bug is there.
Comment 3 Michal Marek 2007-10-11 13:03:04 UTC
Forgot to set NEEDINFO. See comment #2
Comment 4 Michal Marek 2007-10-11 16:02:16 UTC
The backtrace shows that freedirs() in lib/ftp.c tried to free an invalid pointer conn->data->reqdata.proto.ftp->file. I reviewed the code that sets ->file, but I couldn't find a path where it would assign a non-malloced string permanently (it does so temporarily in ftp_parse_url_path(), case FTPFILE_MULTICWD:, but it duplicates it a few lines below). So I can't tell where the bug comes from atm.

Eskil, the additional logs would help! Please create them ASAP, in case the bug depends on the url that the redirector gives you (which can change at any time).
Comment 5 Eskil Bylund 2007-10-11 16:20:49 UTC
Sorry, I wasn't able to reproduce it by the time I got your first reply. Hopefully someone who encounters the bug will find this report and the info on how to get the needed logs.
Comment 6 Michal Marek 2007-10-11 16:29:32 UTC
*** Bug 332105 has been marked as a duplicate of this bug. ***
Comment 7 Michal Marek 2007-10-11 16:58:09 UTC
(In reply to comment #5 from Eskil Bylund)
> Sorry, I wasn't able to reproduce it by the time I got your first reply.

I feared that...


Anyway, if you or someone else is able to reproduce it again, could they also try the 7.17.0 version from factory (libcurl4-7.17.0-*.rpm)? Just in case there's a bug that was already fixed upstream.
Comment 8 Eskil Bylund 2007-10-12 09:31:18 UTC
Created attachment 177999 [details]
Valgrind and strace logs
Comment 9 Eskil Bylund 2007-10-12 09:43:05 UTC
I couldn't find the package you mentioned but I updated the 10.3 package to 7.17.0 and the crash is still there.
Comment 10 Michal Marek 2007-10-12 11:31:15 UTC
Thanks for the logs!


(In reply to comment #9 from Eskil Bylund)
> I couldn't find the package you mentioned but I updated the 10.3 package to
> 7.17.0 and the crash is still there.

The rpm package was not yet synced out, sorry. Thanks for testing 7.17.0. Just for sure, did you overwrite /usr/lib64/libcurl.so.4* (ie. run ./configure --prefix=/usr --libdir=/usr/lib64)?
Comment 11 Eskil Bylund 2007-10-12 11:51:03 UTC
Yes. (I updated the 10.3 curl rpm spec file to 7.17.0 and upgraded to the new package.)
Comment 12 Michal Marek 2007-10-12 11:54:07 UTC
Wow...

$ curl -Lv
http://ftp.uninett.no/pub/linux/opensuse/distribution/10.3/repo/debug/content
* About to connect() to ftp.uninett.no port 80 (#0)
*   Trying 158.36.2.10... connected
* Connected to ftp.uninett.no (158.36.2.10) port 80 (#0)
> GET /pub/linux/opensuse/distribution/10.3/repo/debug/content HTTP/1.1
> User-Agent: curl/7.17.0 (x86_64-suse-linux-gnu) libcurl/7.17.0 OpenSSL/0.9.8e zlib/1.2.3 libidn/1.0
> Host: ftp.uninett.no
> Accept: */*
> 
< HTTP/1.1 302 Found
< Date: Fri, 12 Oct 2007 11:49:37 GMT
< Server: Apache/1.3.37 (Unix) PHP/4.4.4 mod_perl/1.29
< Location:
ftp://ftp.uninett.no/pub/linux/opensuse/distribution/10.3/repo/debug/content
< Transfer-Encoding: chunked
< Content-Type: text/html; charset=iso-8859-1
< 
* Ignoring the response-body
* Connection #0 to host ftp.uninett.no left intact
* Issue another request to this URL:
'ftp://ftp.uninett.no/pub/linux/opensuse/distribution/10.3/repo/debug/content'
* About to connect() to ftp.uninett.no port 21 (#1)
*   Trying 158.36.2.10... connected
* Connected to ftp.uninett.no (158.36.2.10) port 21 (#1)
*** glibc detected *** curl: free(): invalid pointer: 0x00002b01a33115f2 ***
...

The strace helped. I also have a suspect why it happens. Stay tuned.
Comment 13 Michal Marek 2007-10-12 13:30:38 UTC
Peter, does it make sense to disable ftp hosts in the redirector as a temporary woraround? I mean I hope to fix it shortly, but it'll take some time until the update is available...
Comment 14 Michal Marek 2007-10-12 16:08:39 UTC
Darix? Is it possible to stop redirecting to mirrors that do http -> ftp redirects?
Comment 15 Michal Marek 2007-10-12 16:43:04 UTC
OK, the ftp.uninett.no mirror should be disabled now, thanks Darix. If you hit the bug again, please run zypper under strace, look for any 'Location: ftp://' string in the strace output and report the mirror here.

As for the bug itself: I've a workaround for it, discussing a proper fix with upstream [*]. I'm building testing packages in the buildservice, they'll appear here once built: http://download.opensuse.org/repositories/home:/michal-m/openSUSE_10.3 (only libcurl4.rpm was changed).


[*] http://curl.haxx.se/mail/lib-2007-10/index.html#122
Comment 16 Peter Poeml 2007-10-15 05:45:12 UTC
There is one mirror (ftp.is.co.za) which is ftp-only (i.e., we
immediately redirect to ftp://ftp.is.co.za/mirror/opensuse/opensuse/
ourselves. (They have already set up an Apache, I am in contact with
them about that.) Should I disable redirection to them as well? 

Did someone contact uninett.no? If not, I'll talk to them.
Comment 17 Michal Marek 2007-10-15 08:31:51 UTC
(In reply to comment #16 from Peter Poeml)
> There is one mirror (ftp.is.co.za) which is ftp-only (i.e., we
> immediately redirect to ftp://ftp.is.co.za/mirror/opensuse/opensuse/
> ourselves. (They have already set up an Apache, I am in contact with
> them about that.) Should I disable redirection to them as well?

Yes, please do. It's the http -> ftp redirect that libcurl can't handle on 10.3


> Did someone contact uninett.no? If not, I'll talk to them.

Not me. But their setup is perfectly ok, just our tool can't handle it :-/


(In reply to comment #15 from Michal Marek)
> As for the bug itself: I've a workaround for it, discussing a proper fix with
> upstream [*]. I'm building testing packages in the buildservice

Sorry, that didn't work at all. Unfortunately the patch from upstream didn't
help either. Stay tuned...
Comment 18 Peter Poeml 2007-10-15 08:37:47 UTC
Okay, ftp.is.co.za is disabled for now.
Comment 19 Michal Marek 2007-10-16 13:46:58 UTC
I've a patch against CVS HEAD that fixes this, I'm going to backport it to the version used in 10.3.
Comment 20 Michal Marek 2007-10-17 08:59:10 UTC
I finally have testing packages in http://download.opensuse.org/repositories/home:/michal-m/openSUSE_10.3/. I tried adding repos from ftp://ftp.uninett.no/pub/linux/opensuse/distribution/10.3/repo/ and installing packages and all went ok.

Anja, can I get a SWAMP-id for a 10.3 update?
Comment 24 Michal Marek 2007-10-22 09:33:22 UTC
I submitted a fixed curl package to autobuild for 10.3 update. However, we probably shouldn't re-enable the disabled mirrors, because that would break 10.3 GM installations (network installations and adding online repos during install).
Comment 25 Peter Poeml 2007-10-23 19:00:00 UTC
Created attachment 180103 [details]
checking mirrors for FTP redirects

As the attached transcript shows, there is no mirror which redirects to
FTP servers inside the 10.3 repo. So we should be fine for now.
Comment 26 Anja Stock 2007-10-24 15:28:07 UTC
released
Comment 27 Ladislav Slezák 2007-10-29 13:56:48 UTC
*** Bug 333390 has been marked as a duplicate of this bug. ***
Comment 28 Ladislav Slezák 2007-10-29 13:57:31 UTC
*** Bug 333639 has been marked as a duplicate of this bug. ***
Comment 29 Andreas Schwab 2008-04-25 12:22:23 UTC
reset-reqproto.patch references data after free, which causes git-fetch to crash when using http transport.
Comment 30 Andreas Schwab 2008-04-25 12:28:04 UTC
Created attachment 210487 [details]
Testcase

$ make -s curl LDLIBS=-lcurl
$ valgrind ./curl
==17049== Memcheck, a memory error detector.
==17049== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==17049== Using LibVEX rev 1732, a library for dynamic binary translation.
==17049== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==17049== Using valgrind-3.2.3, a dynamic binary instrumentation framework.
==17049== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==17049== For more details, rerun with: -v
==17049== 
4d3a72da3f21761bf4f2866a6a3400d4ecf67365        refs/heads/master
==17049== Invalid read of size 4
==17049==    at 0xFF6B360: conn_free (url.c:1796)
==17049==    by 0xFF6E040: Curl_rm_connc (url.c:487)
==17049==    by 0xFF8143C: curl_multi_cleanup (multi.c:1557)
==17049==    by 0x10001C6C: main (curl.c:46)
==17049==  Address 0x450C57C is 332 bytes inside a block of size 34,176 free'd
==17049==    at 0xFFB8A9C: free (vg_replace_malloc.c:233)
==17049==    by 0xFF713B8: Curl_close (url.c:384)
==17049==    by 0xFF7CE48: curl_easy_cleanup (easy.c:507)
==17049==    by 0x10001C64: main (curl.c:45)
==17049== 
==17049== Invalid write of size 4
==17049==    at 0xFF6B454: conn_free (url.c:1797)
==17049==    by 0xFF6E040: Curl_rm_connc (url.c:487)
==17049==    by 0xFF8143C: curl_multi_cleanup (multi.c:1557)
==17049==    by 0x10001C6C: main (curl.c:46)
==17049==  Address 0x450C57C is 332 bytes inside a block of size 34,176 free'd
==17049==    at 0xFFB8A9C: free (vg_replace_malloc.c:233)
==17049==    by 0xFF713B8: Curl_close (url.c:384)
==17049==    by 0xFF7CE48: curl_easy_cleanup (easy.c:507)
==17049==    by 0x10001C64: main (curl.c:45)
==17049== 
==17049== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 5 from 2)
==17049== malloc/free: in use at exit: 756 bytes in 11 blocks.
==17049== malloc/free: 3,040 allocs, 3,029 frees, 96,621 bytes allocated.
==17049== For counts of detected errors, rerun with: -v
==17049== searching for pointers to 11 not-freed blocks.
==17049== checked 157,464 bytes.
==17049== 
==17049== LEAK SUMMARY:
==17049==    definitely lost: 0 bytes in 0 blocks.
==17049==      possibly lost: 0 bytes in 0 blocks.
==17049==    still reachable: 756 bytes in 11 blocks.
==17049==         suppressed: 0 bytes in 0 blocks.
==17049== Rerun with --leak-check=full to see details of leaked memory.
Comment 31 Michal Marek 2008-04-28 12:20:20 UTC
Does http://cool.haxx.se/cvs.cgi/curl/lib/url.c.diff?r1=1.669&r2=1.670 fix the git-fetch crash?
Comment 34 Harald Mueller-Ney 2008-04-29 15:08:58 UTC
SWAMPID: 17481
for releasing an update.
Comment 35 Michal Marek 2008-04-29 18:32:58 UTC
Submitted a fixed package.
Comment 36 Marcus Meissner 2008-05-19 09:05:48 UTC
update released