Bug 178592 - Libxml++ segfaults because of latest libsigc++ ?
Summary: Libxml++ segfaults because of latest libsigc++ ?
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: libxml++
Version: 4
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Konstantin Ryabitsev
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-01-22 06:21 UTC by Fabrice Colin
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version: 2.12.0-2
Clone Of:
Environment:
Last Closed: 2006-02-13 19:13:41 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Fabrice Colin 2006-01-22 06:21:03 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7

Description of problem:
I am experiencing segfaults in a program of mine that uses libxml++. To find
out where the problem lies, I tried the examples that come with
libxml++-devel and they segault too.

It looks like there's a conflict with libstdc++ (libstdc++-4.0.2-8.fc4).
What makes me say that is :
- that problem appeared after I updated my (then up-to-date) system at
the end of november and installed the afore-mentioned version of libstdc++.
- the backtrace points to gnu_cxx symbols
- the problem goes away if I rebuild libxml++ using the SRPM

If I compile "/usr/share/doc/libxml++-devel-2.12.0/examples/dom_parser/main.cc"
and run the executable against any XML file, say "/etc/gaim/prefs.xml", I'll
get this output :

Node name = pref
Node name = pref
     line = 3
  Attribute version = 1.0
  Attribute name = /
Segmentation fault

gdb shows this backtrace :

(gdb) bt
#0  0x00270483 in __gnu_cxx::__pool<true>::_M_reclaim_block () from /usr/lib/libstdc++.so.6
#1  0x0804a469 in __gnu_cxx::__mt_alloc<std::_List_node<xmlpp::Attribute*>, __gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::deallocate ()
#2  0x0804a485 in std::_List_base<xmlpp::Attribute*, std::allocator<xmlpp::Attribute*> >::_M_put_node ()
#3  0x0804a4ee in std::_List_base<xmlpp::Attribute*, std::allocator<xmlpp::Attribute*> >::_M_clear ()
#4  0x0804a512 in std::_List_base<xmlpp::Attribute*, std::allocator<xmlpp::Attribute*> >::~_List_base$base ()
#5  0x0804a56a in std::list<xmlpp::Attribute*, std::allocator<xmlpp::Attribute*> >::~list ()
#6  0x08049c6e in print_node ()
#7  0x08049ece in main ()

Commenting out parser.set_validate(), line 124, to disable DTD validation
will help testing with any XML file.

This happens every time for me with FC4/i386. I saw it happen on ppc too, but
cannot confirm right now whether the problem still exists on that platform.

Could it be some kind of ABI compatibility issues ? I saw somebody reported
a similar issue (with Debian) on the libxmlplusplus-general mailing list :
http://sourceforge.net/mailarchive/forum.php?thread_id=8989783&forum_id=12784

I hope this helps.

Fabrice

Version-Release number of selected component (if applicable):
libxml++-2.12.0-1.fc4

How reproducible:
Always

Steps to Reproduce:
1. $ cp /usr/share/doc/libxml++-devel-2.12.0/examples/dom_parser/main.cc xmltest.cc
2. Comment out "parser.set_validate();", line 124
3. $ g++ -c xmltest.cc -o xmltest.o `pkg-config --cflags libxml++-2.6`
4. $ libtool --mode=link g++ -fPIC -o xmltest xmltest.o `pkg-config --libs libxml++-2.6`
5. Run against any XML file, for instance $ ./xmltest /etc/gaim/prefs.xml
6. See segfault
7. Get the libxml++ SRPM, rebuild and install RPMs
8. Recompile and relink xmltest, run 5. again : the program will then work correctly

Actual Results:  Step 5 : xmltest fails with this output :

Node name = pref
Node name = pref
     line = 3
  Attribute version = 1.0
  Attribute name = /
Segmentation fault


Expected Results:  xmltest should print a dump of the XML document, as follows :

Node name = pref
Node name = pref
     line = 3
  Attribute version = 1.0
  Attribute name = /


  Node name = pref
Node name = pref
       line = 4
    Attribute name = core
...


Additional info:

Comment 1 Konstantin Ryabitsev 2006-01-26 15:13:02 UTC
Sorry for the delay. I can confirm the segfaults, so I will fire off a rebuild
shortly.


Note You need to log in before you can comment on or make changes to this bug.