Bug#437020: apt-listbugs fails with W: Mandatory parameter 'bug' missing in call to Debbugs::Status::get_bug_status
The problem is reoccurring, but it seems it takes a specific combination of packages to make it happen. I have no idea what's special about that combination, but it causes the server to choke with that error. I can currently reproduce this with the following command: /usr/sbin/apt-listbugs list openoffice.org-core openoffice.org-officebean This bug clearly should be reopened. -- Kevin Brown [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#437020: apt-listbugs fails with W: Mandatory parameter 'bug' missing in call to Debbugs::Status::get_bug_status
I wrote: I can currently reproduce this with the following command: /usr/sbin/apt-listbugs list openoffice.org-core openoffice.org-officebean Here's the debugging output of the above command: Exception `LoadError' at /usr/lib/ruby/1.8/xml/encoding-ja.rb:12 - no such file to load -- uconv Exception `LoadError' at /usr/lib/ruby/1.8/http-access2.rb:31 - no such file to load -- openssl Reading /indices/index.db-critical.gz... Reading /indices/index.db-grave.gz... Reading /indices/index.db-serious.gz... Exception `SOAP::FaultError' at /usr/lib/ruby/1.8/soap/rpc/proxy.rb:180 - Mandatory parameter 'bug' missing in call to Debbugs::Status::get_bug_status at /usr/local/lib/site_perl/Debbugs/SOAP.pm line 131 Exception `SOAP::FaultError' at /usr/lib/ruby/1.8/soap/mapping/mapping.rb:122 - Mandatory parameter 'bug' missing in call to Debbugs::Status::get_bug_status at /usr/local/lib/site_perl/Debbugs/SOAP.pm line 131 http://bugs.debian.org:80/, user-auth=: indexdir = /indices/ Set XSD::XMLParser::XMLParser as XML processor. reading /indices/index.db-critical.gz.. reading /indices/index.db-grave.gz.. reading /indices/index.db-serious.gz.. fetching 438870 440623.. Wire dump: = Request ! CONNECT TO bugs.debian.org:80 ! CONNECTION ESTABLISHED POST /cgi-bin/soap.cgi HTTP/1.1 SOAPAction: Content-Type: text/xml; charset=utf-8 User-Agent: SOAP4R/1.5.5 (/114, ruby 1.8.5 (2006-08-25) [i486-linux]) Date: Fri Sep 07 12:47:02 -0700 2007 Content-Length: 615 Host: bugs.debian.org ?xml version=1.0 encoding=utf-8 ? env:Envelope xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:env=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; env:Body n1:get_status xmlns:n1=Debbugs/SOAP/Status env:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/; bugnumber n2:arrayType=xsd:string[2] xmlns:n2=http://schemas.xmlsoap.org/soap/encoding/; xsi:type=n2:Array item438870/item item440623/item /bugnumber /n1:get_status /env:Body /env:Envelope = Response HTTP/1.1 500 Internal Server Error Date: Fri, 07 Sep 2007 19:47:02 GMT Server: Apache/2.0.54 (Debian GNU/Linux) mod_python/3.1.3 Python/2.3.5 SOAPServer: SOAP::Lite/Perl/0.60 Content-Length: 621 Connection: close Content-Type: text/xml; charset=utf-8 ?xml version=1.0 encoding=UTF-8?SOAP-ENV:Envelope xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:SOAP-ENC=http://schemas.xmlsoap.org/soap/encoding/; xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; SOAP-ENV:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/;SOAP-ENV:BodySOAP-ENV:FaultfaultcodeSOAP-ENV:Server/faultcodefaultstringMandatory parameter 'bug' missing in call to Debbugs::Status::get_bug_status at /usr/local/lib/site_perl/Debbugs/SOAP.pm line 131 /faultstring/SOAP-ENV:Fault/SOAP-ENV:Body/SOAP-ENV:Envelope! CONNECTION CLOSED Exception: SOAP::FaultError W: Mandatory parameter 'bug' missing in call to Debbugs::Status::get_bug_status at /usr/local/lib/site_perl/Debbugs/SOAP.pm line 131 Error retrieving bug reports -- Kevin Brown [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433166: totem-xine: totem stopped working after recent upgrade: no codec is known anymore
I was experiencing this bug as well (with totem-xine). As with the original submitter, installing libxine1-ffmpeg fixed it. The reason I'm replying to this is that I had to install that package *after* I had already installed totem-xine 2.18.2-2 from -unstable. Installing that (as an upgrade to 2.18.2-1) did not install libxine1-ffmpeg. So it appears that this bug still isn't fixed, somehow... -- Kevin Brown [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393636: gnat-gps appears to be completely unusable...
Ludovic Brenta wrote: Kevin Brown [EMAIL PROTECTED] writes: Sounds like I'll wanna grab the current source, but it also sounds like the changes you made and the changes I made are quite similar. Yes, and I just uploaded 4.0.1 which, according to its change log, fixes a few bugs, but not the ones we're interested in. The patches from 4.0.0 applied cleanly, but I also had to add a small patch for GtkAda 2.8.1. With both 4.0.0 and 4.0.1, I get slightly different symptoms from you: (1) GPS hangs, but does not crash, when trying to open a file selector. I too suspect something wrong in GtkAda. Unfortunately there is no unit test for the file selector. Maybe it would be worthwhile to write one. (unless I missed something in testgtk? Look in /usr/share/doc/libgtkada2-doc/examples/testgtk.tar.gz) Hmm...it still crashes on me, consistently. I get the following message: *** glibc detected *** corrupted double-linked list: 0x01b39820 *** Aborted ==22897== Invalid read of size 8 ==22897==at 0x601684E: system__finalization_implementation__attach_to_final_list (in /usr/lib/libgnat-4.1.so.1) Mmm. I don't know what to make of that. I'd like to see a stack trace at that point, is that possible? I'm not sure how to get a stacktrace of a process that's being run underneath valgrind, or if it's even possible. That's something I'll have to investigate. It would be quite nice... By the way, why'd you close this bug? On amd64 the bug is just as valid now as it was before... -- Kevin Brown [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393636: gnat-gps appears to be completely unusable...
Ludovic Brenta wrote: I've just received a new laptop to replace my old IBM ThinkPad T22. The build time for gnat-gps went down from 220 minutes to 17 minutes. It's an HP Compaq nx6325 with dual-core AMD Turion 64x2 TL-60 @2GHz, and 2 GB of RAM. Got it with FreeDOS preloaded instead of Redmond's stuff, too, so I paid no tax on it :). Drool... PS. I'll upload amd64 instead of i386 binaries; wait for the buildds to produce 32-bit binaries. Sounds like I'll wanna grab the current source, but it also sounds like the changes you made and the changes I made are quite similar. Tracking down this issue is proving to be a real headache. The crashes come in two forms: SIGSEGV when allocating or freeing memory (often preceded by glibc throwing a notice of corrupt memory), and an unfielded SIGABRT, often also preceded by the same glibc message. The unhandled SIGABRT is particularly annoying, since it seems that all sorts of signals get thrown around within the application, so I can't just set up my debugger to stop on SIGABRT. It's crashing prior to throwing up the file selector dialog box, or sometimes while it's in the process of doing so. When it manages to get the file selector on the screen, some of the text (e.g., the current directory) is corrupt. So it's definitely a memory corruption issue. I have a nasty suspicion that the problem is in the Ada GTK binding libraries, but I can't at all be certain of that at this point. Are there any unit tests of the Ada GTK binding library? Running them under something like Valgrind or Electric Fence might reveal bugs that would be difficult to find in something more complex like GNAT-GPS. That said, valgrind against the new GNAT-GPS binary you released shows something interesting: ==22897== Invalid write of size 8 ==22897==at 0x60166AF: system__finalization_implementation__detach_from_final_list (in /usr/lib/libgnat-4.1.so.1) ==22897==by 0x601674D: system__finalization_implementation__finalize_one (in /usr/lib/libgnat-4.1.so.1) There are 3 of those, as well as one of these: ==22897== Invalid read of size 8 ==22897==at 0x601684E: system__finalization_implementation__attach_to_final_list (in /usr/lib/libgnat-4.1.so.1) These sound to me like they are attempting to read/write pointers, but what was allocated was an int. And this is also interesting (there are 4 of these): ==22897== Address 0xA088160 is 120 bytes inside a block of size 968 free'd Anyway, I'll keep working on it as I find the time, but it's tough going at the moment... -- Kevin Brown [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393636: gnat-gps appears to be completely unusable...
Ludovic Brenta wrote: I don't think -gnatE buys you anything, as GNAT's default, static elaboration model is more strict. Is the static elaboration model always in force? That is, if I use -gnatE, do I get both static *and* dynamic elaboration checks? That would be preferable, IMO. Nevertheless, the following patch (applied in Monotone in branch org.debian.gnat-gps.3.1.3) should take care of the Program_Error. Applied. Thanks! I applied the same fix to the other two files that use String_Hash. And the end result? It still crashes, but it doesn't smash the stack while doing so like it did before. And using the new file button actually works. Debugging under gdb doesn't work with the -gstabs+ option because the debugger isn't able to access any of the stack-allocated objects in the Ada code. See: http://www.mail-archive.com/osg-users@openscenegraph.net/msg04734.html I switched gps.gpr over to -ggdb and all is well on that front now. It's currently crashing in a free that's being called from glib.convert.locale_from_utf8(). I'm in the process of compiling up libgtkada2-2.8.1 with full debugging. -- Kevin Brown [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393636: gnat-gps appears to be completely unusable...
I wrote: Family comes first. Take your time. This is not by any means urgent at all. By the way, I compiled with -gnatE so that it would do runtime elaboration checks. Now when I run the program I get this: raised PROGRAM_ERROR : basic_mapper.ads:76 access before elaboration That line is this: package Double_String_Table is new String_Hash (String_Access, False_Free, No_Element); I did the same thing with gnat-gps-4.0.0 and got exactly the same error at exactly the same place: basic_mapper.ads:76. Any ideas on how to address this, or at least how to figure out what exactly it thinks is being accessed before elaboration? -- Kevin Brown [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393636: gnat-gps appears to be completely unusable...
Ludovic Brenta wrote: Yes, now the fun begins. You can say break exception and look at the backtrace at the point where the exception was raised. Sorry I can't be of any more help right now, my wife and baby son are both ill and I need to take care of them. Family comes first. Take your time. This is not by any means urgent at all. By the way, I compiled with -gnatE so that it would do runtime elaboration checks. Now when I run the program I get this: raised PROGRAM_ERROR : basic_mapper.ads:76 access before elaboration That line is this: package Double_String_Table is new String_Hash (String_Access, False_Free, No_Element); What do I have to do to fix this? -- Kevin Brown [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393636: gnat-gps appears to be completely unusable...
I wrote: Why can't I run gnatgdb against this? Turns out that the version of gnat-gdb in -testing is rather old: from 2003! Upgrading to the version in -unstable fixed this problem, and it's now able to attach to the LWP. Not that it helped a whole lot. The stack trace looks like it's smashed just as in the other gdb run. Here's what it looks like just the same: [EMAIL PROTECTED]:~$ LD_LIBRARY_PATH=/usr/lib/debug gnatgdb /usr/src/Debian/Ada/GPS/3.1.3-3/gnat-gps-3.1.3/gnat-gps GNU gdb 6.4 for GNAT Pro 2006 (20060522) Copyright 2005 Free Software Foundation, Inc. Ada Core Technologies version of GDB for GNAT Professional GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. See your support agreement for details of warranty and support. If you do not have a current support agreement, then there is absolutely no warranty for this version of GDB. Type show warranty for details. This GDB was configured as x86_64-linux-gnu...Using host libthread_db library /usr/lib/debug/libthread_db.so.1. (gdb) run Starting program: /usr/src/Debian/Ada/GPS/3.1.3-3/gnat-gps-3.1.3/gnat-gps [Thread debugging using libthread_db enabled] [New Thread 47757512239440 (LWP 9045)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 47757512239440 (LWP 9045)] signal_key_cmp (node1=0x15731fd, node2=0xfda02b00) at gsignal.c:700 700 gsignal.c: No such file or directory. in gsignal.c Current language: auto; currently c (gdb) where #0 signal_key_cmp (node1=0x15731fd, node2=0xfda02b00) at gsignal.c:700 #1 0x2b6f67a98e85 in signal_parse_name (name=value optimized out, itype=value optimized out, detail_p=0x1, force_quark=9) at gbsearcharray.h:163 #2 0x01809650 in C.920.17735 () #3 0x7fb3d830 in ?? () #4 0x7fb40560 in ?? () (gdb) cont Continuing. raised STORAGE_ERROR : s-intman.adb:158 explicit raise Program exited with code 01. (gdb) -- Kevin Brown [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393636: gnat-gps appears to be completely unusable...
Ludovic Brenta wrote: Hi Kevin, Your help will be definitely appreciated. At first, I wanted to replace GPS 2.1.0 with the newest version, 4.0.0. I had some trouble compiling it but finally succeeded and found that it would crash with a Storage_Error whenever opening a project, or any file for that matter. If the exception is the same as what I'm getting here, then chances are it's generating a SIGSEGV. Given the problems that 3.1.3 seems to be having, it sounds like it might be worth our while to concentrate on 4.0.0 instead. But since you're the primary maintainer, that's your call. :-) I'm compiling with a bunch of additional switches now and getting a bunch of warnings, some of which are very definitely indicative of this application not being 64-bit clean, such as: ada_module.adb:205:13: warning: types for unchecked conversion have different sizes ada_module.adb:205:13: warning: size of Gulong is 64, size of Discrete_Type is 32 ada_module.adb:205:13: warning: 32 high order bits of source will be ignored That might be bad, but this looks to be much worse: gps-kernel-modules.adb:1274:13: warning: types for unchecked conversion have different sizes gps-kernel-modules.adb:1274:13: warning: size of BASE_TYPE is 32, size of ADDRESS is 64 gps-kernel-modules.adb:1274:13: warning: source will be extended with 32 high order sign bits Such errors can be found in a number of places. Here are the Builder and Compiler package stanzas I'm using in gps.gpr: package Builder is for Default_Switches (Ada) use (-k, -a, -m); for Executable (gps-main) use gnat-gps; end Builder; package Compiler is for Default_Switches (Ada) use (-g, -O0, -gnatafno, -gnatVa, -fstack-check, -gnatE, -gnatD); for Switches (gvd-canvas.adb) use (-O0, -gnatafno, -gnatVa, -fstack-check, -gnatE, -gnatD); for Switches (codefix-text_manager.adb) use (-g, -O0, -gnatafno, -gnatVa, -gnatE, -gnatD); end Compiler; I also added -g to the Default_Switches list for the Linker package. I made the exception for gvd-canvas.adb in order to get it past the compiler bug, and for codefix-text_manager.adb because with '-fstack-check' it would throw the following compiler error: codefix-text_manager.adb:2301:45: dynamically tagged expression not allowed I'd like to somehow fix the source so that the tagged expression error doesn't occur with -fstack-check but I don't know how to fix that type of error just yet. What exactly does it imply in this context? Finally, I get lots of warnings like this with '-fstack-check': /usr/src/Debian/Ada/GPS/3.1.3-3/gnat-gps-3.1.3/gps/src/gps-main.adb:1676: warning: frame size too large for reliable stack checking How can I increase whatever limit it's using to determine that the frame size is too large? -- Kevin Brown [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393636: gnat-gps appears to be completely unusable...
Package: gnat-gps Version: 3.1.3-2 Severity: grave Justification: renders package unusable Note that I am using the amd64 version, so that may be relevant here. I haven't tried using the i386 version. Basically, it seems that gnat-gps is completely unusable. If I open an existing project (hello.gpr), it acts as if it didn't open anything, and a second attempt to open the project (or, indeed, to open any file at all) throws this error: raised STORAGE_ERROR : s-intman.adb:158 explicit raise The above also occurs when I tell it to start with a default project in any directory and then attempt to open a file. If I attempt to create a new standalone project with the wizard, gnat-gps goes into an infinite loop and appears to never come out of it. The bottom line is that, at least on the amd64 platform, gnat-gps appears to be completely unusable. I'll be happy to help debug this however I can, but keep in mind that I'm rather new to Ada (it's been 15 years or so since I've done anything with it, and that was only a college course at that). -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-amd64-generic Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages gnat-gps depends on: ii libc62.3.6.ds1-4 GNU C Library: Shared libraries ii libgcc1 1:4.1.1-13 GCC support library ii libglib2.0-0 2.12.3-2The GLib library of C routines ii libgnat-4.1 4.1.1-15Runtime library for GNU Ada applic ii libgnatprj4.14.1.1-15GNU Ada Project Manager ii libgnatvsn4.14.1.1-15GNU Ada compiler version library ii libgtk2.0-0 2.8.20-1The GTK+ graphical user interface ii libgtkada-2.82.8.1-4 Ada binding for the GTK library ii libpango1.0-01.14.5-1Layout and rendering of internatio ii libtemplates-parser1010.0+20060522-4 Ada library to parse files and rep ii python2.42.4.3-8 An interactive high-level object-o ii tcl8.4 8.4.12-1.1 Tcl (the Tool Command Language) v8 Versions of packages gnat-gps recommends: ii ada-reference-m 20021112web-3The standard describing the Ada 95 ii gnat4.1.1-11 The GNU Ada compiler ii gnat-gdb5.3.gnat.0.0.20030225-12 Ada-aware version of GDB pn gnat-gps-docnone (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393636: gnat-gps appears to be completely unusable...
Ludovic Brenta wrote: If you would like to help debug GPS, please start by downloading the source package and editing the top-level gps.gpr file. Look for package Builder, and add -g to the Default_Switches (Ada) line, e.g. package Builder is for Default_Switches (Ada) use (-g, ...); end Builder; then do debian/rules gnat-gps. After a long time (3h40 on my old laptop but only 48 minutes on an AMD64 buildd) you will end up with a large file called gnat-gps, containing debugging information. You can run that under gdb or (better) gnatgdb from the package gnat-gdb. The latter allows you to break on exceptions (break exception), so you can see where the Storage_Error is being raised. I grabbed the 3.1.3-3 source and am building that. With the default build options (no -g) it builds fine but behaves the same way as 3.1.3-2. With the -g option added to Default_Switches, I get the following: gcc-4.1 -c -g -gnatafno -gnatVa -I- -gnatA /usr/src/Debian/Ada/GPS/3.1.3-3/gnat-gps-3.1.3/gvd/gvd/gvd-canvas.adb +===GNAT BUG DETECTED==+ | 4.1.2 20060928 (prerelease) (Debian 4.1.1-15) (x86_64-pc-linux-gnu) GCC error:| | in splice_child_die, at dwarf2out.c:5503 | | Error detected at histories.ads:191:15 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html. | | Use a subject line meaningful to you and us to track the bug. | | Include the entire contents of this bug box in the report. | | Include the exact gcc-4.1 or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. with a nice long list of files. :-( You may also want to try removing all compiler options; maybe the compiler is emitting wrong code or something. In particular, I usually compile with -gnato (full range checks, so we could get a Constraint_Error) and -gnatVa (full optional run-time checks, which can raise various exceptions). If you remove these options, you'll stand a lesser chance of getting exceptions and a higher chance of getting random memory corruption and segfaults :/ Hmm...I'll experiment a bit with that. -- Kevin Brown [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393636: gnat-gps appears to be completely unusable...
Ludovic Brenta wrote: Hi Kevin, Thanks for trying to help. Try this in gps.gpr: package Compiler is for Default_Switches (Ada) use ... (do not change) for Switches (gvd-canvas.adb) use (-g, -O0); end Compiler; and do debian/rules gnat-gps again. This yields the same compilation error. (what I actually did was to retain the use of -g in package Builder and to change the -O2 in Compiler's Default_Switches to -O0, but that's equivalent for gvd-canvas.adb) -- Kevin Brown [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393636: gnat-gps appears to be completely unusable...
I wrote: Ludovic Brenta wrote: Hi Kevin, Thanks for trying to help. Try this in gps.gpr: package Compiler is for Default_Switches (Ada) use ... (do not change) for Switches (gvd-canvas.adb) use (-g, -O0); end Compiler; and do debian/rules gnat-gps again. This yields the same compilation error. That said, just to test things I disabled -g just for that one source file to get it past it. It turns out that (if I remember -- I'm away from that computer at the moment) it's the last file to be compiled prior to linking. I tried using gnatgdb against the resulting file but it seems unable to attach to the resulting LWP that gets created. GDB gives better results. When running the program, the program winds up getting a SIGSEGV. It looks to me like the storage manager catches that and raises its own exception. GDB puts me into C mode, which isn't going to help a whole lot for debugging this. Why can't I run gnatgdb against this? -- Kevin Brown [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393636: gnat-gps appears to be completely unusable...
I wrote: GDB gives better results. When running the program, the program winds up getting a SIGSEGV. It looks to me like the storage manager catches that and raises its own exception. Here's the results of a gdb run against the binary: [EMAIL PROTECTED]:/usr/src/Debian/Ada/GPS/3.1.3-3/gnat-gps-3.1.3$ gdb gnat-gps GNU gdb 6.4.90-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as x86_64-linux-gnu...Using host libthread_db library /lib/libthread_db.so.1. (gdb) run Starting program: /usr/src/Debian/Ada/GPS/3.1.3-3/gnat-gps-3.1.3/gnat-gps [Thread debugging using libthread_db enabled] [New Thread 46951004957008 (LWP 31813)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 46951004957008 (LWP 31813)] 0x2ab3a0150e3c in signal_parse_name (name=0x7ff029b8 Pp$\002, itype=value optimized out, detail_p=0x85a2e482322a, force_quark=-1281144710) at gsignal.c:281 281 gsignal.c: No such file or directory. in gsignal.c Current language: auto; currently c (gdb) where #0 0x2ab3a0150e3c in signal_parse_name (name=0x7ff029b8 Pp$\002, itype=value optimized out, detail_p=0x85a2e482322a, force_quark=-1281144710) at gsignal.c:281 #1 0x in ?? () (gdb) cont Continuing. raised STORAGE_ERROR : s-intman.adb:158 explicit raise Program exited with code 01. (gdb) quit The SIGSEGV occurred when I tried to open a file. This doesn't look very useful, especially given that I can't even get a traceback. :-( -- Kevin Brown [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353489: rhythmbox: UI freezes and quickly becomes unusable during normal operation
Lo?c Minier wrote: Hi, On sam, f?v 18, 2006, Kevin Brown wrote: It's possible this bug is somehow AMD64-specific... Yes, it seems likely. I'll be reverting to 0.8.8-13 until this bug gets fixed. Going back and forth between this version and 0.8.8-13 is quite easy, so I'll be happy to perform any testing you might need. ii gstreamer0.10-alsa [gs 0.10.2-2 ALSA plugin for GStreamer ii gstreamer0.10-gnomevfs 0.10.2-2 Gnome VFS plugin for GStreamer ii gstreamer0.10-plugins- 0.10.2-2 Collection of various GStreamer pl ii gstreamer0.10-plugins- 0.10.1-2 Collection of various GStreamer pl ii gstreamer0.10-plugins- 0.10.1-1 Collection of various GStreamer pl Be sure to update your plugins to the latest version: - gstreamer0.10-plugins-base to 0.10.3-1 - gstreamer0.10-plugins-good to 0.10.2-1 and let me know whether that helps. That actually seems to have cleared up the problem. Interesting. Guess you can go ahead and close this one. If I run into any further trouble I'll file a new bug. Thanks! -- Kevin Brown [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353489: rhythmbox: UI freezes and quickly becomes unusable during normal operation
Package: rhythmbox Version: 0.9.3.1-1 Severity: grave Justification: renders package unusable This version of rhythmbox appears to be unusable. After it comes up, I can select a song to play and begin playing it. Afterwards, any attempt to do anything (pause the song, move to a different location in the song, etc.) will cause the entire UI to freeze for several seconds at least, if not permanently. And by entire UI I mean the whole thing, including repainting the UI widgets when, e.g., a window is moved over it. The song continues to play while this is occurring. Version 0.8.8-13 doesn't have these issues at all, and I can successfully revert rhythmbox back to that version and regain proper functionality. It's possible this bug is somehow AMD64-specific... I'll be reverting to 0.8.8-13 until this bug gets fixed. Going back and forth between this version and 0.8.8-13 is quite easy, so I'll be happy to perform any testing you might need. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-amd64-generic Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages rhythmbox depends on: ii dbus 0.60-5simple interprocess messaging syst ii gconf2 2.12.1-9 GNOME configuration database syste ii gstreamer0.10-alsa [gs 0.10.2-2 ALSA plugin for GStreamer ii gstreamer0.10-gnomevfs 0.10.2-2 Gnome VFS plugin for GStreamer ii gstreamer0.10-plugins- 0.10.2-2 Collection of various GStreamer pl ii gstreamer0.10-plugins- 0.10.1-2 Collection of various GStreamer pl ii gstreamer0.10-plugins- 0.10.1-1 Collection of various GStreamer pl ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi ii libatk1.0-01.10.3-1 The ATK accessibility toolkit ii libaudiofile0 0.2.6-6 Open-source version of SGI's audio ii libavahi-client3 0.6.6-1 Avahi client library ii libavahi-common3 0.6.6-1 Avahi common library ii libavahi-compat-howl0 0.6.6-1 Avahi Howl compatibility library ii libavahi-glib1 0.6.6-1 Avahi glib integration library ii libbonobo2-0 2.10.1-1 Bonobo CORBA interfaces library ii libbonoboui2-0 2.10.1-2 The Bonobo UI library ii libc6 2.3.6-1 GNU C Library: Shared libraries an ii libcairo2 1.0.2-3 The Cairo 2D vector graphics libra ii libdbus-1-20.60-5simple interprocess messaging syst ii libdbus-glib-1-2 0.60-5simple interprocess messaging syst ii libesd00.2.36-3 Enlightened Sound Daemon - Shared ii libexpat1 1.95.8-3 XML parsing C library - runtime li ii libfontconfig1 2.3.2-1.1 generic font configuration library ii libfreetype6 2.1.10-1 FreeType 2 font engine, shared lib ii libgconf2-42.12.1-9 GNOME configuration database syste ii libgcrypt111.2.2-1 LGPL Crypto library - runtime libr ii libglade2-01:2.5.1-2 library to load .glade files at ru ii libglib2.0-0 2.8.6-1 The GLib library of C routines ii libgnome-keyring0 0.4.6-2 GNOME keyring services library ii libgnome2-02.12.0.1-5The GNOME 2 library - runtime file ii libgnomecanvas2-0 2.12.0-2 A powerful object-oriented display ii libgnomeui-0 2.12.1-1 The GNOME 2 libraries (User Interf ii libgnomevfs2-0 2.12.2-5 GNOME virtual file-system (runtime ii libgnutls111.0.16-14 GNU TLS library - runtime library ii libgpg-error0 1.1-4 library for common error values an ii libgpod0 0.3.0-2 a library to read and write songs ii libgstreamer0.10-0 0.10.3-1 Core GStreamer libraries, plugins, ii libgtk2.0-02.8.12-1 The GTK+ graphical user interface ii libhal10.5.6-3 Hardware Abstraction Layer - share ii libice66.9.0.dfsg.1-4Inter-Client Exchange library ii libjpeg62 6b-11 The Independent JPEG Group's JPEG ii libmusicbrainz4c2a 2.1.2-2 Second generation incarnation of t ii libnautilus-burn2 2.12.2-3 Nautilus Burn Library - runtime ve ii libnotify1 0.3.2-1 sends desktop notifications to a n ii liborbit2 1:2.12.4-1libraries for ORBit2 - a CORBA ORB ii libpango1.0-0 1.10.3-1 Layout and rendering of internatio ii libpng12-0 1.2.8rel-5PNG library - runtime ii libpopt0 1.7-5
Bug#321644: mozilla-browser: This bug is completely reproducible for me
Package: mozilla-browser Version: 2:1.7.12-1 Followup-For: Bug #321644 There's a web page at work that I use occasionally that triggers this bug every time. Recompiling with -g -O instead of -g -O2 fixed it. Since changing the optimizer flags causes the crashes in question to disappear for me and apparently others as well, I think it's pretty clear we're talking about an optimizer bug here. Patches to the mozilla code probably aren't going to be as effective as simply changing the optimizer flags to something that's more reliable. Since a number of other platforms use -O and not -O2 (possibly for similar reasons), the most reasonable approach here is to use -O on the amd64 architecture. One other thing: this same optimization bug appears in gcc 3.4 as well (I attempted to compile mozilla using gcc 3.4 but ran into the same problem). So it's something that's been around a while. Anyone wanna file a bug against gcc on this? -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-amd64-generic Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages mozilla-browser depends on: ii debconf 1.4.67 Debian configuration management sy ii libatk1.0-0 1.10.3-1 The ATK accessibility toolkit ii libc6 2.3.5-11 GNU C Library: Shared libraries an ii libfontconfig12.3.2-1.1 generic font configuration library ii libfreetype6 2.1.10-1 FreeType 2 font engine, shared lib ii libgcc1 1:4.0.2-6 GCC support library ii libglib2.0-0 2.8.5-1The GLib library of C routines ii libgtk2.0-0 2.8.9-2The GTK+ graphical user interface ii libnspr4 2:1.7.12-1 Netscape Portable Runtime Library ii libpango1.0-0 1.10.2-1 Layout and rendering of internatio ii libstdc++64.0.2-6The GNU Standard C++ Library v3 ii libx11-6 6.9.0.dfsg.1-2 X Window System protocol client li ii libxext6 6.9.0.dfsg.1-2 X Window System miscellaneous exte ii libxft2 2.1.7-1FreeType-based font drawing librar ii libxp66.9.0.dfsg.1-2 X Window System printing extension ii libxrender1 1:0.9.0.2-1X Rendering Extension client libra ii libxt66.9.0.dfsg.1-2 X Toolkit Intrinsics ii psmisc21.9-1 Utilities that use the proc filesy ii xlibs 6.9.0.dfsg.1-3 X Window System client libraries m ii zlib1g1:1.2.3-9 compression library - runtime Versions of packages mozilla-browser recommends: ii mozilla-psm 2:1.7.12-1 The Mozilla Internet application s ii myspell-en-gb [myspell-dictio 1:2.0.1-2 English_british dictionary for mys ii myspell-en-us [myspell-dictio 1:2.0.1-2 English_american dictionary for my -- debconf information: mozilla/dsp: none mozilla/locale_auto: true * mozilla/prefs_note: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#346013: mozilla: Confirmed...
Package: mozilla Version: 2:1.7.12-1kev Followup-For: Bug #346013 Yeah, I've confirmed this. Same problem, same solution, arrived at independently. :-) By the way, Teemu, your crashing problem is likely due to an optimizer bug in gcc. Try modifying your debian/rules file and change line 41 from this: OPTFLAGS=-g -O2 -DDEBIAN to: OPTFLAGS=-g -O -DDEBIAN See bug 321644 on that issue. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-amd64-generic Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages mozilla depends on: ii dpkg 1.13.11 package maintenance system for Deb ii mozilla-browser2:1.7.12-1kev The Mozilla Internet application s ii mozilla-mailnews 2:1.7.12-1kev The Mozilla Internet application s ii mozilla-psm2:1.7.12-1kev The Mozilla Internet application s mozilla recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332726: mono-apache-server: mod-mono-server claims that mod_mono and xsp have different versions
Package: mono-apache-server Version: 1.0.5-2 Severity: grave Justification: renders package unusable Seems all the mod-mono functionality is now broken, and apache returns a code 500 (internal server error) for all of it. So in order to find out what was going on, I started mod-mono-server by hand, thusly: su www-data -c '/usr/bin/mono /usr/share/dotnet/bin/mod-mono-server.exe --filename /tmp/.mod_mono_server --nonstop --appconfigdir /etc/mono-server' I then hit the web server (http://localhost/samples) and got the following output: [EMAIL PROTECTED]:/etc/mono-server# su www-data -c '/usr/bin/mono /usr/share/dotnet/bin/mod-mono-server.exe --filename /tmp/.mod_mono_server --nonstop --appconfigdir /etc/mono-server' mod-mono-server Listening on: /tmp/.mod_mono_server Root directory: /etc/mono-server In ModMonoWorker.Run: mod_mono and xsp have different versions. And yet, both mono-apache-server and mono-xsp packages are at 1.0.5-2! However, the mono framework itself is now at 1.1.9.1. In any case, this situation renders mod_mono completely dead, hence the grave severity of this bug. This bug is actually probably a dup of 303755, but the submitter of that bug marked it as normal and didn't give any useful information. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages mono-apache-server depends on: ii debconf 1.4.58 Debian configuration management sy ii libapache-mod-mono1.0-1 Run ASP.NET Pages on UNIX with Apa ii mono-classlib-1.0 1.1.9.1-3 Mono class library (1.0) ii mono-jit 1.1.9.1-3 fast CLI (.NET) JIT compiler for M ii mono-mcs 1.1.9.1-3 Mono C# compiler mono-apache-server recommends no packages. -- debconf information: * monoserver/monoserver_restartapache: true -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317873: Apt Paclkage Dependency Bug
Justin Pryzby [EMAIL PROTECTED] wrote: You are probably running unstable, and this is probably related to the in-progress g++ abi transition: Changes: aspell (0.60.3-2) unstable; urgency=low . * debian/control: renamed libaspell15 to libaspell15c2 for the * GCC 4.0 ABI change transition If you intend to continue running unstable, you'd better prepare yourself for more of this. Isn't this sort of thing what experimental is for? I'm somewhat unfamiliar with Debian policy, but I'm a bit surprised that this transition is happening in -unstable instead of -experimental. I thought -experimental was where all the distribution-breaking changes were supposed to occur... -- Kevin Brown [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317873: Apt Paclkage Dependency Bug
Brian Nelson wrote: Transitions are impossible in experimental because they'll never get into unstable on their own. Hmm...given the amount of breakage this transition seems to be causing, it might be worth creating a staging distribution for the purpose of such transitions, so that -unstable doesn't end up being broken for extended periods of time. I thought -experimental was where all the distribution-breaking changes were supposed to occur... No, that's what unstable is for. Experimental is for stuff that isn't release-ready. Packages being rebuilt for the GCC 4.0 transition *are* release-ready--they just temporarily break other stuff the archive. Any idea how temporary this particular transition is likely to be? It's been going on for a little while now. I can work around it, by holding back the appropriate packages, but it is something of a pain. I do realize that there are tradeoffs for running in the -unstable branch, but to be honest I didn't expect the possibility of multi-week distribution breakage to be one of them. -- Kevin Brown [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
