| Summary: | Kopete crash after update, when trying to add Jabber account | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Max <7workers> | ||||
| Component: | ucommon | Assignee: | David Sugar <dyfet> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 17 | CC: | alekcejk, dennis, dyfet, honza, h.pillay, jreznik, kevin, ltinkl, mael.lavault, pfessel, ppitonak, rdieter, rnovacek, rob.dyck, smparrish, than, wes, xjakub | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2012-07-05 23:37:24 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Attachments: |
|
||||||
|
Description
Max
2012-06-19 13:57:42 UTC
I can confirm this issue on Fedora 17. As a workaround, it is enough to comment out the [Account_JabberProtocol_<jabberaccount>] section (by "#"). ...sorry, forgot to mention: this section is in the .kde/share/config/kopeterc file. This appears to be a bug in ucommon (which is where libcommoncpp.so.5 comes from). It would be nice to have a backtrace with debugging information (from GDB, with at least ucommon-debuginfo and glibc-debuginfo installed) though. Offhand I am surprised kopete is using libcommoncpp. That this appears to be in the constructor for IPV4Host is curious, too. I actually do see a number of problematic issues with this constructor, though, which is amusing for such an especially short bit of code, and I am guessing it is most likely with the statically initialized _host_ object itself, for most other uses would seem potentially broken. This machinary all seemed designed to avoid multiple gethostname() calls and probably should be scrapped and simplified. I would like to see a more complete backtrace also, though, or at least before proposing a specific fix or patch. Kevin, thanks, please have a look at the upstream report I just linked, a full backtrace is there. (In reply to comment #4) > Offhand I am surprised kopete is using libcommoncpp. kopete_jabber.so depends on libortp built against libzrtpcpp and libcommoncpp. See also bug 824267. I have a simple patch to try. Meantime I am going to look at having a special 5.2.3 build for this.
diff --git i/commoncpp/address.cpp w/commoncpp/address.cpp
index 24eeb2b..967d154 100644
--- i/commoncpp/address.cpp
+++ w/commoncpp/address.cpp
@@ -360,7 +360,7 @@ void IPV4Address::setAddress(const char *host)
if(ipaddr)
delete[] ipaddr;
ipaddr = new struct in_addr[1];
- memset((void *)&ipaddr[0], 0, sizeof(ipaddr));
+ memset((void *)&ipaddr[0], 0, sizeof(struct in_addr));
return;
}
@@ -498,7 +498,7 @@ IPV6Address::IPV6Address(const IPV6Validator *_validator)
: validator(_validator), hostname(NULL) {
addr_count = 1;
ipaddr = new struct in6_addr[1];
- memcpy(ipaddr, &in6addr_any, sizeof(in6_addr));
+ memcpy(ipaddr, &in6addr_any, sizeof(struct in6_addr));
}
IPV6Address::IPV6Address(const char *address, const IPV6Validator *_validator) :
@@ -716,7 +716,7 @@ void IPV6Address::setAddress(const char *host)
if(ipaddr)
delete[] ipaddr;
ipaddr = new struct in6_addr[1];
- memset((void *)&ipaddr[0], 0, sizeof(ipaddr));
+ memset((void *)&ipaddr[0], 0, sizeof(struct in6_addr));
return;
}
@@ -796,7 +796,7 @@ void IPV6Address::setAddress(const char *host)
if(ipaddr)
delete[] ipaddr;
ipaddr = new struct in6_addr[1];
- memset((void *)&ipaddr[0], 0, sizeof(ipaddr));
+ memset((void *)&ipaddr[0], 0, sizeof(struct in6_addr));
return;
}
(In reply to comment #7) > I have a simple patch to try. Meantime I am going to look at having a > special 5.2.3 build for this. Should it fix crash from bug 824267? I can confirm it solves the issue, David, thanks a lot! Here is a quick and dirty scratch build for F17: http://koji.fedoraproject.org/koji/taskinfo?taskID=4199843 Offhand, I think it also fixes 824267. I may not have a chance to do an official build for F17 until later tonight (yes, I am an upstream that also maintains my packages in F17 ;). But that will 5.2.3. I also am going to update to 5.4.2 for rawhide (F18) with this fix... ucommon-5.2.3-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/ucommon-5.2.3-1.fc17 I can confirm no crush after updating to ucommon-5.2.3-1.fc17 Thanks a lot guys! Great job! Package ucommon-5.2.3-1.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing ucommon-5.2.3-1.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-10013/ucommon-5.2.3-1.fc17 then log in and leave karma (feedback). *** Bug 824267 has been marked as a duplicate of this bug. *** 5.2.3-1 corrected this issue for me as well, thanks for the quick update. Did not start backtrace_rating: 4 Package: linphone-3.5.2-3.fc17 OS Release: Fedora release 17 (Beefy Miracle) Created attachment 595871 [details]
File: backtrace
Sorry about the duplicate report. It was generated by the bug reporting tool. Updating ucommon fixed linphone. ucommon-5.2.3-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report. *** Bug 833733 has been marked as a duplicate of this bug. *** twinkle is broken despite this update: *** buffer overflow detected ***: twinkle terminated ======= Backtrace: ========= /lib64/libc.so.6(__fortify_fail+0x37)[0x34897097c7] /lib64/libc.so.6[0x3489707980] /lib64/libccgnu2-1.8.so.0[0x3497e28e73] /lib64/libccgnu2-1.8.so.0(_ZN3ost8IPV4HostC1EPKc+0xa8)[0x3497e295f8] /lib64/libcommoncpp.so.5[0x3493e20091] /lib64/ld-linux-x86-64.so.2[0x348920ee26] /lib64/ld-linux-x86-64.so.2[0x348920eee0] /lib64/ld-linux-x86-64.so.2[0x348920156a] ======= Memory map: ======== 00400000-00714000 r-xp 00000000 fd:00 674471 /usr/bin/twinkle 00913000-00919000 rw-p 00313000 fd:00 674471 /usr/bin/twinkle 00b18000-00b66000 rw-p 00318000 fd:00 674471 /usr/bin/twinkle 025c1000-025e2000 rw-p 00000000 00:00 0 [heap] 3489200000-3489220000 r-xp 00000000 fd:00 665035 /usr/lib64/ld-2.15.so 348941f000-3489420000 r--p 0001f000 fd:00 665035 /usr/lib64/ld-2.15.so 3489420000-3489421000 rw-p 00020000 fd:00 665035 /usr/lib64/ld-2.15.so 3489421000-3489422000 rw-p 00000000 00:00 0 3489600000-34897ac000 r-xp 00000000 fd:00 665323 /usr/lib64/libc-2.15.so 34897ac000-34899ac000 ---p 001ac000 fd:00 665323 /usr/lib64/libc-2.15.so 34899ac000-34899b0000 r--p 001ac000 fd:00 665323 /usr/lib64/libc-2.15.so 34899b0000-34899b2000 rw-p 001b0000 fd:00 665323 /usr/lib64/libc-2.15.so 34899b2000-34899b7000 rw-p 00000000 00:00 0 3489a00000-3489afa000 r-xp 00000000 fd:00 670534 /usr/lib64/libm-2.15.so 3489afa000-3489cf9000 ---p 000fa000 fd:00 670534 /usr/lib64/libm-2.15.so 3489cf9000-3489cfa000 r--p 000f9000 fd:00 670534 /usr/lib64/libm-2.15.so 3489cfa000-3489cfb000 rw-p 000fa000 fd:00 670534 /usr/lib64/libm-2.15.so 3489e00000-3489e03000 r-xp 00000000 fd:00 665440 /usr/lib64/libdl-2.15.so 3489e03000-348a002000 ---p 00003000 fd:00 665440 /usr/lib64/libdl-2.15.so 348a002000-348a003000 r--p 00002000 fd:00 665440 /usr/lib64/libdl-2.15.so 348a003000-348a004000 rw-p 00003000 fd:00 665440 /usr/lib64/libdl-2.15.so 348a200000-348a216000 r-xp 00000000 fd:00 668075 /usr/lib64/libpthread-2.15.so 348a216000-348a416000 ---p 00016000 fd:00 668075 /usr/lib64/libpthread-2.15.so 348a416000-348a417000 r--p 00016000 fd:00 668075 /usr/lib64/libpthread-2.15.so 348a417000-348a418000 rw-p 00017000 fd:00 668075 /usr/lib64/libpthread-2.15.so 348a418000-348a41c000 rw-p 00000000 00:00 0 348a600000-348a607000 r-xp 00000000 fd:00 665469 /usr/lib64/librt-2.15.so 348a607000-348a806000 ---p 00007000 fd:00 665469 /usr/lib64/librt-2.15.so 348a806000-348a807000 r--p 00006000 fd:00 665469 /usr/lib64/librt-2.15.so 348a807000-348a808000 rw-p 00007000 fd:00 665469 /usr/lib64/librt-2.15.so 348aa00000-348aa17000 r-xp 00000000 fd:00 665418 /usr/lib64/libz.so.1.2.5 348aa17000-348ac16000 ---p 00017000 fd:00 665418 /usr/lib64/libz.so.1.2.5 348ac16000-348ac17000 rw-p 00016000 fd:00 665418 /usr/lib64/libz.so.1.2.5 348ae00000-348ae15000 r-xp 00000000 fd:00 669994 /usr/lib64/libgcc_s-4.7.0-20120507.so.1 348ae15000-348b014000 ---p 00015000 fd:00 669994 /usr/lib64/libgcc_s-4.7.0-20120507.so.1 348b014000-348b015000 rw-p 00014000 fd:00 669994 /usr/lib64/libgcc_s-4.7.0-20120507.so.1 348b200000-348b314000 r-xp 00000000 fd:00 679271 /usr/lib64/libboost_regex.so.1.48.0 348b314000-348b513000 ---p 00114000 fd:00 679271 /usr/lib64/libboost_regex.so.1.48.0 348b513000-348b518000 r--p 00113000 fd:00 679271 /usr/lib64/libboost_regex.so.1.48.0 348b518000-348b51b000 rw-p 00118000 fd:00 679271 /usr/lib64/libboost_regex.so.1.48.0 348b600000-348b616000 r-xp 00000000 fd:00 665566 /usr/lib64/libresolv-2.15.so 348b616000-348b816000 ---p 00016000 fd:00 665566 /usr/lib64/libresolv-2.15.so 348b816000-348b817000 r--p 00016000 fd:00 665566 /usr/lib64/libresolv-2.15.so 348b817000-348b818000 rw-p 00017000 fd:00 665566 /usr/lib64/libresolv-2.15.so 348b818000-348b81a000 rw-p 00000000 00:00 0 348ba00000-348ba02000 r-xp 00000000 fd:00 675121 /usr/lib64/libXau.so.6.0.0 348ba02000-348bc02000 ---p 00002000 fd:00 675121 /usr/lib64/libXau.so.6.0.0 348bc02000-348bc03000 r--p 00002000 fd:00 675121 /usr/lib64/libXau.so.6.0.0 348bc03000-348bc04000 rw-p 00003000 fd:00 675121 /usr/lib64/libXau.so.6.0.0 348be00000-348be1d000 r-xp 00000000 fd:00 675157 /usr/lib64/libxcb.so.1.1.0 348be1d000-348c01c000 ---p 0001d000 fd:00 675157 /usr/lib64/libxcb.so.1.1.0 348c01c000-348c01d000 r--p 0001c000 fd:00 675157 /usr/lib64/libxcb.so.1.1.0 348c01d000-348c01e000 rw-p 0001d000 fd:00 675157 /usr/lib64/libxcb.so.1.1.0 348c200000-348c26e000 r-xp 00000000 fd:00 679324 /usr/lib64/libmng.so.1.0.0 348c26e000-348c46e000 ---p 0006e000 fd:00 679324 /usr/lib64/libmng.so.1.0.0 348c46e000-348c471000 r--p 0006e000 fd:00 679324 /usr/lib64/libmng.so.1.0.0 348c471000-348c473000 rw-p 00071000 fd:00 679324 /usr/lib64/libmng.so.1.0.0 348c600000-348c734000 r-xp 00000000 fd:00 676484 /usr/lib64/libX11.so.6.3.0 348c734000-348c934000 ---p 00134000 fd:00 676484 /usr/lib64/libX11.so.6.3.0 348c934000-348c935000 r--p 00134000 fd:00 676484 /usr/lib64/libX11.so.6.3.0 348c935000-348c93a000 rw-p 00135000 fd:00 676484 /usr/lib64/libX11.so.6.3.0 348ca00000-348ca10000 r-xp 00000000 fd:00 679418 /usr/lib64/libXext.so.6.4.0 348ca10000-348cc10000 ---p 00010000 fd:00 679418 /usr/lib64/libXext.so.6.4.0 Abortado (imagem do núcleo gravada) I've reported this problem (842213), but it's been marked as a duplicate of this bug. Hard to say for sure, the backtrace in bug#842213 doesn't look useful (missing a lot of -debuginfo, glibc in particular) If you could get a new backtrace, that would be helpful. Twinkle is still using the much older commoncpp2 library, rather than commoncpp2 from ucommon, at least from what I gather from the above dump. The bug fixed in ucommon certainly existed in the last releases of commoncpp2 from several years ago as well. I do have a patch set that can be used for twinkle to use the newer ccrtp/ucommon/cppzrtp libraries. I actually suggest going that route, if the twinkle package maintainer wishes to apply it. Otherwise we could do a simple patch for the older (pre-ucommon) commoncpp2 libs. I don't maintain either of these in Fedora though. I agree twinkle should have a new or separate bug report for this in any case. where is this "much older commoncpp2 library" to which you refer? As far as I can tell, twinkle links against commoncpp2 from ucommon.
$ ldd /usr/bin/twinkle | grep common
libcommoncpp.so.5 => /lib64/libcommoncpp.so.5 (0x00007fbc91a96000)
libucommon.so.5 => /lib64/libucommon.so.5 (0x00007fbc918200)
$ rpm -q -f /lib64/libcommoncpp.so.5 /lib64/libucommon.so.5
ucommon-5.2.3-1.fc17.x86_64
ucommon-5.2.3-1.fc17.x86_64
Rex, I was looking at his published dump and it ALSO shows libccgnu2-1.8.so! |