Bug#561681: crashes on startup
Dave Beckett writes: > >>From the stack trace I can see a problem - the librdf is calling the old > rasqal ABI (0.9.16) in librasqal.so.1 rather than the new (0.9.17) in > librasqal.so.2. (Assuming these are redland librdf 1.0.10 and rasqal librdf > 0.9.17) > > redland 1.0.10 (librdf.so.0) was packaged to link with the new rasqal 0.9.17 > (librasqal.so.2) and so the above stack trace should not be possible, unless > I've got the shared lib/package dependencies wrong. Let's check the reporter's versions: ii librasqal1 0.9.16-2Rasqal RDF query library ii librdf0 1.0.10-1Redland Resource Description Frame Hm. Let's check the package dependencies: Package: librdf0 Source: redland Version: 1.0.10-1 Architecture: i386 Depends: libc6 (>= 2.3), libdb4.8, libltdl7 (>= 2.2.6b), libraptor1 (>= 1.4.19), librasqal2 (>= 0.9.17) We see that ardour links against librasqal1, while librdf0 links against librasqal2. This indicates a problems with transitive dependencies of the rasqal package: Both versions are loaded into the address space of the application, probably with colliding symbols. > Maybe librasqal2 should conflict with librasqal1. With the conflicts you prevent both libraries to be co-installed and cause potentially a difficult transition for the 'testing' migration. Have you analyzed how many packages are affected by this? All reverse dependencies on librasqal1 need to be transitioned. If this affects a larger portion of packages, this might warrant a discussion on debian-release or debian-devel. The most elegant solution i see here would be to introduce symbol versioning in the librasqal package so that applications that have not been transitioned yet to librasqal2 package can easily co-exist. BTW, I'm currently doing essentially the same in the ffmpeg package atm. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#561681: crashes on startup
Adrian Knoth wrote: > On Sat, Dec 19, 2009 at 05:02:21PM +0100, hungerburg wrote: > > Hi! > >> the last time I used ardour two days ago. I believe it was >> 1:2.8.4-1 - today after updating to 1:2.8.4-2 I can no longer >> launch the application. A downgrade does not help. Maybe its >> because a file changed that ardour uses but that is in another >> package. > > We have to sort things out. I claim that it's not an ardour bug, > ardour's working fine over here and you say that downgrading doesn't fix > the bug, so it's very likely not ardour's fault. > > I'll reassign the bug to the appropriate package once we know the > culprit. > >> Below valgrind output shows an invalid memory access while >> loading lv2 plugins. I am not aware that debian ships any of >> those though or that such plugins are installed on this >> system here. > > We do have LV2 plugins in Debian, however, ardour's LV2 code is rather > stable. See below. > >> ==29391== Jump to the invalid address stated on the next line >> ==29391==at 0xC: ??? >> ==29391==by 0x58CEF8F: rasqal_engine_execute_init (in >> /usr/lib/librasqal.so.1.0.0) >> ==29391==by 0x58CA128: rasqal_query_execute (in >> /usr/lib/librasqal.so.1.0.0) >> ==29391==by 0x58A8781: ??? (in /usr/lib/librdf.so.0.0.0) >> ==29391==by 0x58A5D49: librdf_query_execute (in /usr/lib/librdf.so.0.0.0) >> ==29391==by 0x595A83D: slv2_world_load_specifications (in >> /usr/lib/libslv2.so.9.2.0) >> ==29391==by 0x595AE93: slv2_world_load_all (in /usr/lib/libslv2.so.9.2.0) >> ==29391==by 0x424E262: ARDOUR::LV2World::LV2World() (in >> /usr/lib/ardour2/libardour.so) >> ==29391==by 0x4198453: ARDOUR::PluginManager::PluginManager() (in >> /usr/lib/ardour2/libardour.so) >> ==29391==by 0x41462D0: ARDOUR::init(bool, bool) (in >> /usr/lib/ardour2/libardour.so) >> ==29391==by 0x816080C: ARDOUR_UI::ARDOUR_UI(int*, char***) (in >> /usr/lib/ardour2/ardour-2.8.4) >> ==29391== Address 0xc is not stack'd, malloc'd or (recently) free'd > > Here we go. As always, stack traces are bottom up. We see that ardour > calls some LV2 functions which are handled by libslv2. This library does > the whole LV2 discovery stuff. > > Further up the stack trace, we see librdf executing a query, which is > then passed to librasqal. > > Both libs, librdf and librasqal, have new versions in unstable since > yesterday, so I guess one of them is the culprit: > >http://packages.qa.debian.org/r/redland.html > >http://packages.qa.debian.org/r/rasqal.html > > (new versions on 2009-12-17) > > > When I downgrade librdf0 to 1.0.9-3, ardour starts fine. > > > That's why I would say librdf0 is the real culprit here. > > I'm now building ardour against new librdf0 to see if this fixes the > issue, but I don't think so. (libs are expected to be backward > compatible, that is, ardour built against librdf0-1.0.9 should run with > librdf0-1.0.10. > > > However, I'll CC the librdf0 maintainer, so he has the chance to do some > investigations himself. > >From the stack trace I can see a problem - the librdf is calling the old rasqal ABI (0.9.16) in librasqal.so.1 rather than the new (0.9.17) in librasqal.so.2. (Assuming these are redland librdf 1.0.10 and rasqal librdf 0.9.17) redland 1.0.10 (librdf.so.0) was packaged to link with the new rasqal 0.9.17 (librasqal.so.2) and so the above stack trace should not be possible, unless I've got the shared lib/package dependencies wrong. Maybe librasqal2 should conflict with librasqal1. Dave ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#561681: crashes on startup
On Sat, Dec 19, 2009 at 05:02:21PM +0100, hungerburg wrote: Hi! > the last time I used ardour two days ago. I believe it was > 1:2.8.4-1 - today after updating to 1:2.8.4-2 I can no longer > launch the application. A downgrade does not help. Maybe its > because a file changed that ardour uses but that is in another > package. We have to sort things out. I claim that it's not an ardour bug, ardour's working fine over here and you say that downgrading doesn't fix the bug, so it's very likely not ardour's fault. I'll reassign the bug to the appropriate package once we know the culprit. > Below valgrind output shows an invalid memory access while > loading lv2 plugins. I am not aware that debian ships any of > those though or that such plugins are installed on this > system here. We do have LV2 plugins in Debian, however, ardour's LV2 code is rather stable. See below. > ==29391== Jump to the invalid address stated on the next line > ==29391==at 0xC: ??? > ==29391==by 0x58CEF8F: rasqal_engine_execute_init (in > /usr/lib/librasqal.so.1.0.0) > ==29391==by 0x58CA128: rasqal_query_execute (in > /usr/lib/librasqal.so.1.0.0) > ==29391==by 0x58A8781: ??? (in /usr/lib/librdf.so.0.0.0) > ==29391==by 0x58A5D49: librdf_query_execute (in /usr/lib/librdf.so.0.0.0) > ==29391==by 0x595A83D: slv2_world_load_specifications (in > /usr/lib/libslv2.so.9.2.0) > ==29391==by 0x595AE93: slv2_world_load_all (in /usr/lib/libslv2.so.9.2.0) > ==29391==by 0x424E262: ARDOUR::LV2World::LV2World() (in > /usr/lib/ardour2/libardour.so) > ==29391==by 0x4198453: ARDOUR::PluginManager::PluginManager() (in > /usr/lib/ardour2/libardour.so) > ==29391==by 0x41462D0: ARDOUR::init(bool, bool) (in > /usr/lib/ardour2/libardour.so) > ==29391==by 0x816080C: ARDOUR_UI::ARDOUR_UI(int*, char***) (in > /usr/lib/ardour2/ardour-2.8.4) > ==29391== Address 0xc is not stack'd, malloc'd or (recently) free'd Here we go. As always, stack traces are bottom up. We see that ardour calls some LV2 functions which are handled by libslv2. This library does the whole LV2 discovery stuff. Further up the stack trace, we see librdf executing a query, which is then passed to librasqal. Both libs, librdf and librasqal, have new versions in unstable since yesterday, so I guess one of them is the culprit: http://packages.qa.debian.org/r/redland.html http://packages.qa.debian.org/r/rasqal.html (new versions on 2009-12-17) When I downgrade librdf0 to 1.0.9-3, ardour starts fine. That's why I would say librdf0 is the real culprit here. I'm now building ardour against new librdf0 to see if this fixes the issue, but I don't think so. (libs are expected to be backward compatible, that is, ardour built against librdf0-1.0.9 should run with librdf0-1.0.10. However, I'll CC the librdf0 maintainer, so he has the chance to do some investigations himself. HTH -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#561681: crashes on startup
Package: ardour-i686 Version: 1:2.8.4-2 Severity: grave the last time I used ardour two days ago. I believe it was 1:2.8.4-1 - today after updating to 1:2.8.4-2 I can no longer launch the application. A downgrade does not help. Maybe its because a file changed that ardour uses but that is in another package. Below valgrind output shows an invalid memory access while loading lv2 plugins. I am not aware that debian ships any of those though or that such plugins are installed on this system here. Hopefully somebody can make use of below information: I setup the script that loads ardour to valgrind it. the limit should not matter, does it? # WARNING: Your system has a limit for maximum amount of locked memory! This might cause Ardour to run out of memory before your system runs out of memory. You can view the memory limit with 'ulimit -l', and it is normally controlled by /etc/security/limits.conf ==29391== Memcheck, a memory error detector ==29391== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==29391== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for copyright info ==29391== Command: /usr/lib/ardour2/ardour-2.8.4 ==29391== Ardour/GTK 2.8.4 (built using 6077 and GCC version 4.4.2) Copyright (C) 1999-2008 Paul Davis Some portions Copyright (C) Steve Harris, Ari Johnson, Brett Viren, Joel Baker Ardour comes with ABSOLUTELY NO WARRANTY not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This is free software, and you are welcome to redistribute it under certain conditions; see the source for copying conditions. loading default ui configuration file /etc/ardour2/ardour2_ui_default.conf loading user ui configuration file /home/dub/.ardour2/ardour2_ui.conf Loading ui configuration file /etc/ardour2/ardour2_ui_dark.rc theme_init() called from internal clearlooks engine ardour: [INFO]: Ardour will be limited to 1014 open files loading system configuration file /etc/ardour2/ardour_system.rc loading user configuration file /home/dub/.ardour2/ardour.rc ardour: [INFO]: No H/W specific optimizations in use ==29391== Jump to the invalid address stated on the next line ==29391==at 0xC: ??? ==29391==by 0x58CEF8F: rasqal_engine_execute_init (in /usr/lib/librasqal.so.1.0.0) ==29391==by 0x58CA128: rasqal_query_execute (in /usr/lib/librasqal.so.1.0.0) ==29391==by 0x58A8781: ??? (in /usr/lib/librdf.so.0.0.0) ==29391==by 0x58A5D49: librdf_query_execute (in /usr/lib/librdf.so.0.0.0) ==29391==by 0x595A83D: slv2_world_load_specifications (in /usr/lib/libslv2.so.9.2.0) ==29391==by 0x595AE93: slv2_world_load_all (in /usr/lib/libslv2.so.9.2.0) ==29391==by 0x424E262: ARDOUR::LV2World::LV2World() (in /usr/lib/ardour2/libardour.so) ==29391==by 0x4198453: ARDOUR::PluginManager::PluginManager() (in /usr/lib/ardour2/libardour.so) ==29391==by 0x41462D0: ARDOUR::init(bool, bool) (in /usr/lib/ardour2/libardour.so) ==29391==by 0x816080C: ARDOUR_UI::ARDOUR_UI(int*, char***) (in /usr/lib/ardour2/ardour-2.8.4) ==29391== Address 0xc is not stack'd, malloc'd or (recently) free'd ==29391== ==29391== ==29391== Process terminating with default action of signal 11 (SIGSEGV) ==29391== Bad permissions for mapped region at address 0xC ==29391==at 0xC: ??? ==29391==by 0x58CEF8F: rasqal_engine_execute_init (in /usr/lib/librasqal.so.1.0.0) ==29391==by 0x58CA128: rasqal_query_execute (in /usr/lib/librasqal.so.1.0.0) ==29391==by 0x58A8781: ??? (in /usr/lib/librdf.so.0.0.0) ==29391==by 0x58A5D49: librdf_query_execute (in /usr/lib/librdf.so.0.0.0) ==29391==by 0x595A83D: slv2_world_load_specifications (in /usr/lib/libslv2.so.9.2.0) ==29391==by 0x595AE93: slv2_world_load_all (in /usr/lib/libslv2.so.9.2.0) ==29391==by 0x424E262: ARDOUR::LV2World::LV2World() (in /usr/lib/ardour2/libardour.so) ==29391==by 0x4198453: ARDOUR::PluginManager::PluginManager() (in /usr/lib/ardour2/libardour.so) ==29391==by 0x41462D0: ARDOUR::init(bool, bool) (in /usr/lib/ardour2/libardour.so) ==29391==by 0x816080C: ARDOUR_UI::ARDOUR_UI(int*, char***) (in /usr/lib/ardour2/ardour-2.8.4) ==29391== ==29391== HEAP SUMMARY: ==29391== in use at exit: 2,469,368 bytes in 57,769 blocks ==29391== total heap usage: 233,153 allocs, 175,384 frees, 10,941,411 bytes allocated ==29391== ==29391== LEAK SUMMARY: ==29391==definitely lost: 3,583 bytes in 24 blocks ==29391==indirectly lost: 10,200 bytes in 522 blocks ==29391== possibly lost: 686,605 bytes in 11,538 blocks ==29391==still reachable: 1,768,980 bytes in 45,685 blocks ==29391== suppressed: 0 bytes in 0 blocks ==29391== Rerun with --leak-check=full to see details of leaked memory ==29391== ==29391== For counts of detected and suppressed errors, rerun with: -v ==29391== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 244 from 11) Killed # -- System Information: Debian Release: squeeze/sid APT prefers un
