Bug 636960

Summary:	wrong gcc version for atomicity.h
Product:	[Fedora] Fedora	Reporter:	Piscium <groknok>
Component:	glibmm24	Assignee:	Jakub Jelinek <jakub>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	low	Docs Contact:
Priority:	low
Version:	13	CC:	debarshir, groknok, jakub, kalevlember, karlthered
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-09-24 06:49:29 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Piscium 2010-09-23 19:09:12 UTC

Description of problem:

While debugging an issue on a program of mine I came across what it appears like a packaging issue with gcc (though the issue could be in another package). As the trace further below shows, it is looking for file atomicity.h in directory 4.4.3 while I have installed version 4.4.4 of gcc. I _do_ have that particular file in 4.4.4.

Version-Release number of selected component (if applicable):

4.4.4

How reproducible:

Always (that is, until I fix the bug in my program!).

Steps to Reproduce:
1. gdb my_program_name
2. run
3. make my program crash (by closing main program window, as there is a bug in my program)
  
Actual results:

It cannot find atomicity in directory 4.4.3.

Expected results:

It should not be looking for the file in that directory as I have 4.4.4.

Additional info:

Trace I got that shows issue:

Program received signal SIGSEGV, Segmentation fault.
0x03c9ef06 in __exchange_and_add (this=0x80592e0, __in_chrg=<value optimized out>) at /usr/include/c++/4.4.3/ext/atomicity.h:46
46	/usr/include/c++/4.4.3/ext/atomicity.h: No such file or directory.
	in /usr/include/c++/4.4.3/ext/atomicity.h
Missing separate debuginfos, use: debuginfo-install freetype-freeworld-2.3.11-2.fc13.i686
(gdb) backtrace
#0  0x03c9ef06 in __exchange_and_add (this=0x80592e0, __in_chrg=<value optimized out>) at /usr/include/c++/4.4.3/ext/atomicity.h:46
#1  __exchange_and_add_dispatch (this=0x80592e0, __in_chrg=<value optimized out>) at /usr/include/c++/4.4.3/ext/atomicity.h:79
#2  _M_dispose (this=0x80592e0, __in_chrg=<value optimized out>) at /usr/include/c++/4.4.3/bits/basic_string.h:234
#3  ~basic_string (this=0x80592e0, __in_chrg=<value optimized out>) at /usr/include/c++/4.4.3/bits/basic_string.h:503
#4  Glib::ustring::~ustring (this=0x80592e0, __in_chrg=<value optimized out>) at ustring.cc:351
#5  0x0804abcc in ~Object (argc=1, argv=0xbffff414) at object.hpp:27
#6  _Destroy<Object> (argc=1, argv=0xbffff414) at /usr/lib/gcc/i686-redhat-linux/4.4.4/../../../../include/c++/4.4.4/bits/stl_construct.h:83
#7  __destroy<Object*> (argc=1, argv=0xbffff414) at /usr/lib/gcc/i686-redhat-linux/4.4.4/../../../../include/c++/4.4.4/bits/stl_construct.h:93
#8  _Destroy<Object*> (argc=1, argv=0xbffff414) at /usr/lib/gcc/i686-redhat-linux/4.4.4/../../../../include/c++/4.4.4/bits/stl_construct.h:116
#9  _Destroy<Object*, Object> (argc=1, argv=0xbffff414) at /usr/lib/gcc/i686-redhat-linux/4.4.4/../../../../include/c++/4.4.4/bits/stl_construct.h:142
#10 ~vector (argc=1, argv=0xbffff414) at /usr/lib/gcc/i686-redhat-linux/4.4.4/../../../../include/c++/4.4.4/bits/stl_vector.h:313
#11 main (argc=1, argv=0xbffff414) at main.cpp:239

Comment 1 Jakub Jelinek 2010-09-23 19:16:03 UTC

Likely some object files were compiled with an older gcc.

Comment 2 Piscium 2010-09-24 00:59:24 UTC

Jakub, you were right. I downloaded, rebuilt and installed  glibmm24-2.24.1-1.fc13.src.rpm and the warning about atomicity.h not being found disappeared.

So the issue is really with the glibmm24-2.24.1-1.fc13.src.rpm package (not gcc).

I think this is a very minor bug, but I am reassigning the package to glibmm and will let the glibmm maintainer decide about it.

Comment 3 Kalev Lember 2010-09-24 06:49:29 UTC

Thanks for the report, but it's certainly not a glibmm package bug. GCC in stable Fedora releases is often updated to new bug fix releases and we're not going to rebuild most of the packages in an already-released distro just because of that.

Comment 4 Piscium 2010-09-24 08:09:56 UTC

It makes sense. Thanks.