Bug#1022051: /boot/vmlinuz-5.10.0-19-amd64: Same Here
Package: src:linux Version: 5.10.149-1 Followup-For: Bug #1022051 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Maintainer, * What led up to the situation? Normal kernal package upgrade and reboot. * What exactly did you do (or not do) that was effective (or ineffective)? 5.10.0-18 works fine. 5.10.0-19 always hangs with "flip_done timed out" before I can get even a text console. * What was the outcome of this action? Using older kernel for now. * What outcome did you expect instead? 5.10.0-19 bootable. - -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: To Be Filled By O.E.M. product_name: To Be Filled By O.E.M. product_version: To Be Filled By O.E.M. chassis_vendor: Default string chassis_version: Default string bios_vendor: American Megatrends Inc. bios_version: P2.00 board_vendor: ASRock board_name: X399 Taichi board_version: ** Network interface configuration: *** /etc/network/interfaces: auto lo iface lo inet loopback ** PCI devices: 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Root Complex [1022:1450] Subsystem: ASRock Incorporation Family 17h (Models 00h-0fh) Root Complex [1849:1450] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:01.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) PCIe GPP Bridge [1022:1453] (prog-if 00 [Normal decode]) Subsystem: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) PCIe GPP Bridge [1022:1453] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:02.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller [1022:790b] (rev 59) Subsystem: ASRock Incorporation FCH SMBus Controller [1849:] Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- Kernel driver in use: xhci_hcd Kernel modules: xhci_pci 01:00.1 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] X399 Series Chipset SATA Controller [1022:43b6] (rev 02) (prog-if 01 [AHCI 1.0]) Subsystem: ASMedia Technology Inc. X399 Series Chipset SATA Controller [1b21:1062] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: ahci Kernel modules: ahci 01:00.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] X399 Series Chipset PCIe Bridge [1022:43b1] (rev 02) (prog-if 00 [Normal decode]) Subsystem: ASMedia Technology Inc. X399 Series Chipset PCIe Bridge [1b21:0201] Control: I/
Bug#977901: chromium: Inconsistent SEGV
On Wednesday, December 23, 2020 4:30:48 AM CST Boyd Stephen Smith Jr. wrote: > On Wednesday, December 23, 2020 4:19:43 AM CST Michel Le Bihan wrote: > > The Debian patch for #963548 > > https://salsa.debian.org/mimi8/chromium/-/blob/ece23b4ca107cd968ac9a40 > > 9f > > 40eb11edf8a0266/debian/patches/fixes/serviceworker-double-destruction.pat > > ch is clearly in upstream 87.0.4280.88: > > https://source.chromium.org/chromium/chromium/src/+/refs/tags/87.0.4280.88 > > :c > > ontent/browser/service_worker/service_worker_container_host.cc;l=671-679 > > Different destructor. The old patch is for ServiceWorkerObjectHost, but we > need a new patch for ServiceWorker*Registration*ObjectHost. In particular, just above where you linked to, at line 629 (https:// source.chromium.org/chromium/chromium/src/+/refs/tags/87.0.4280.88:content/ browser/service_worker/service_worker_container_host.cc;l=629) is the crashing line. The fix for the back trace I finally got is to change that line like so: https://source.chromium.org/chromium/chromium/src/+/ f27ad210062f61d06eb782214ee4fc8c19a1725b:content/browser/service_worker/ service_worker_container_host.cc;l=623-647 The f27ed21 commit does contain the fix for #963548, but lower down at line 689: https://source.chromium.org/chromium/chromium/src/+/ f27ad210062f61d06eb782214ee4fc8c19a1725b:content/browser/service_worker/ service_worker_container_host.cc;l=689-697 -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) Twitter: @DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Bug#977901: chromium: Inconsistent SEGV
On Wednesday, December 23, 2020 4:19:43 AM CST Michel Le Bihan wrote: > The Debian patch for #963548 > https://salsa.debian.org/mimi8/chromium/-/blob/ece23b4ca107cd968ac9a409f > 40eb11edf8a0266/debian/patches/fixes/serviceworker-double-destruction.patch > is clearly in upstream 87.0.4280.88: > https://source.chromium.org/chromium/chromium/src/+/refs/tags/87.0.4280.88:c > ontent/browser/service_worker/service_worker_container_host.cc;l=671-679 Different destructor. The old patch is for ServiceWorkerObjectHost, but we need a new patch for ServiceWorker*Registration*ObjectHost. > I also think that it might be an upstream bug, but can't confirm unless > tested and reproducible in Google Chrome. https://bugs.chromium.org/p/chromium/issues/detail?id=1135070 is originally reported against *Chrome* 87.0.4278.0 -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) Twitter: @DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Bug#977901: Similarities to 963548
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963548 also has a fix (https://salsa.debian.org/chromium-team/chromium/-/commit/ b904fa41d40b967dcc8f6984db52f7a2f6a2c83d) related to the cyclic SerivceWorker.*ObjectHost objects and their deletion. The chromium team noticed the same thing: https://bugs.chromium.org/p/ chromium/issues/detail?id=1135070#c15 (in the other direction) It's been an Chromium issue for a while with no clear fix on how to handle cyclic service dependencies in general: https://bugs.chromium.org/p/chromium/ issues/detail?id=1135070#c18 -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) Twitter: @DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Bug#977901: chromium: Inconsistent SEGV
On Wednesday, December 23, 2020 3:49:06 AM CST Boyd Stephen Smith Jr. wrote: > On Wednesday, December 23, 2020 2:38:32 AM CST Boyd Stephen Smith Jr. wrote: > > I got a crash (attached) > > Looks like https://bugs.chromium.org/p/chromium/issues/detail?id=1135070 to > me, which has a fix, but I haven't yet figured out what release(s) the fix > made it into. Doesn't look to me like it has made it into a release at all, but I'm just using the Git tools to navigate the repository, not all the depot tools. ---8<--- bss@monster % git tag -l --contains f27ad210062f61d06eb782214ee4fc8c19a1725b bss@monster % git branch -r --contains f27ad210062f61d06eb782214ee4fc8c19a1725b --list origin/HEAD -> origin/master origin/lkgr origin/lkgr-android-internal origin/lkgr-ios-internal origin/master --->8--- So, I guess it's an "upstream" bug? -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) Twitter: @DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Bug#977901: chromium: Inconsistent SEGV
On Wednesday, December 23, 2020 2:38:32 AM CST Boyd Stephen Smith Jr. wrote: > I got a crash (attached) Looks like https://bugs.chromium.org/p/chromium/issues/detail?id=1135070 to me, which has a fix, but I haven't yet figured out what release(s) the fix made it into. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) Twitter: @DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Bug#977901: chromium: Inconsistent SEGV
On Tuesday, December 22, 2020 11:22:21 PM CST Boyd Stephen Smith Jr. wrote: > I'll have to play around with disabling extensions to see which one(s) cause > a crash within 30 minutes. Super annoying since I do use every one of them > literally every day. :( Looks like maybe Proxy SwitchyOmega (which is thankfully open source). Things had been going fine under the debugger for hours with no extensions, and then I got a crash (attached) within minutes of enabling it. Unfortunately, I need this extension enabled in order to access client network websites behind a proxy server behind a VPN. So, I'm not sure what I can do (or if I can even reproduce the error). -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) Twitter: @DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ Thread 1 "chromium" received signal SIGABRT, Aborted. __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x73857537 in __GI_abort () at abort.c:79 #2 0x5a982805 in base::debug::BreakDebugger() () #3 0x5a909ed6 in logging::LogMessage::~LogMessage() () #4 0x5a90a24e in logging::LogMessage::~LogMessage() () #5 0x5a90bc4a in base::subtle::RefCountedBase::ReleaseImpl() const () #6 0x5930078b in content::ServiceWorkerRegistrationObjectHost::~ServiceWorkerRegistrationObjectHost() () #7 0x593007ce in content::ServiceWorkerRegistrationObjectHost::~ServiceWorkerRegistrationObjectHost() () #8 0x58821ca7 in std::_Rb_tree > >, std::_Select1st > > >, std::less, std::allocator > > > >::_M_erase(std::_Rb_tree_node > > >*) () #9 0x592a97c3 in content::ServiceWorkerContainerHost::~ServiceWorkerContainerHost() () #10 0x592dfd99 in content::ServiceWorkerHost::~ServiceWorkerHost() () #11 0x5932f921 in content::ServiceWorkerVersion::~ServiceWorkerVersion() () #12 0x5932fbde in content::ServiceWorkerVersion::~ServiceWorkerVersion() () #13 0x592fc847 in content::ServiceWorkerRegistration::~ServiceWorkerRegistration() () #14 0x592fc89e in content::ServiceWorkerRegistration::~ServiceWorkerRegistration() () #15 0x593007a0 in content::ServiceWorkerRegistrationObjectHost::~ServiceWorkerRegistrationObjectHost() () #16 0x593007ce in content::ServiceWorkerRegistrationObjectHost::~ServiceWorkerRegistrationObjectHost() () #17 0x58821ca7 in std::_Rb_tree > >, std::_Select1st > > >, std::less, std::allocator > > > >::_M_erase(std::_Rb_tree_node > > >*) () #18 0x58b98403 in std::_Rb_tree > >, std::_Select1st > > >, std::less, std::allocator > > > >::_M_erase_aux(std::_Rb_tree_const_iterator > > >, std::_Rb_tree_const_iterator > > >) () #19 0x58f36e3c in mojo::ReceiverSetBase >, void>::OnDisconnect(unsigned long, unsigned int, std::__cxx11::basic_string, std::allocator > const&) () #20 0x5af13f9f in mojo::InterfaceEndpointClient::NotifyError(base::Optional const&) () #21 0x5af1a5a7 in mojo::internal::MultiplexRouter::ProcessNotifyErrorTask(mojo::internal::MultiplexRouter::Task*, mojo::internal::MultiplexRouter::ClientCallBehavior, base::SequencedTaskRunner*) () #22 0x5af188b9 in mojo::internal::MultiplexRouter::ProcessTasks(mojo::internal::MultiplexRouter::ClientCallBehavior, base::SequencedTaskRunner*) () #23 0x5af1770e in mojo::internal::MultiplexRouter::OnPipeConnectionError(bool) () #24 0x5af11128 in mojo::Connector::HandleError(bool, bool) () #25 0x5af2aebe in mojo::SimpleWatcher::OnHandleReady(int, unsigned int, mojo::HandleSignalsState const&) () #26 0x5af2b336 in base::internal::Invoker, int, unsigned int, mojo::HandleSignalsState>, void ()>::RunOnce(base::internal::BindStateBase*) () #27 0x5a9497d4 in base::TaskAnnotator::RunTask(char const*, base::PendingTask*) () #28 0x5a959aa9 in base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWorkImpl(base::sequence_manager::LazyNow*) () #29 0x5a9597ac in base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWork() () #30 0x5a90d8da in base::MessagePumpGlib::Run(base::MessagePump::Delegate*) () #31 0x5a95a10d in base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run(bool, base::TimeDelta) () #32 0x5a9301a0 in base::RunLoop::Run() () #33 0x5aae564c in ChromeBrowserMainParts::MainMessageLoopRun(int*) () #34 0x58ecb8a2 in content::BrowserMainLoop::RunMainMessageLoopParts() () #35 0
Bug#977901: chromium: Inconsistent SEGV
On Tuesday, December 22, 2020 10:47:31 PM CST Boyd Stephen Smith Jr. wrote: > All my extensions were pulled down during the Google Sync and ran fine on 87 > for roughly an hour -- that's twice as long as my longest browser session > for version 87 on the old profile. > > I still convinced this is a bug -- nothing in my profile should cause a > SEGV, ref_count violation, or corrupted double-linked list. But, there's > at least a workaround, that I'm going to take advantage of, to create a > new, blank profile and either sync or manually import (or likely a > combination of both) all your settings into the new profile. So, it seems one of the _settings_ of one of my extensions is causing the problem. Restored my _settings_ (same list of extensions), and got a crash in 10 minutes. *That* is annoying, but not a chromium bug. Feel free to close this at your leisure. I'll have to play around with disabling extensions to see which one(s) cause a crash within 30 minutes. Super annoying since I do use every one of them literally every day. :( -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) Twitter: @DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Bug#977901: chromium: Inconsistent SEGV
On Tuesday, December 22, 2020 5:26:04 PM CST Boyd Stephen Smith Jr. wrote: > On Tue, 22 Dec 2020 23:43:23 +0100 Michel Le Bihan wrote: > > I was not able to reproduce those crashes. > > That's unfortunate. I'm up to 50 just today. I'm probably going to have to > downgrade to 83 at least until there's another update. Downgrading was a mixed bag (browser was stable, but audio/video stopped working (!)) . So, I tried again with 87. Rather than just disabling my extensions, I tried from a brand-new profile and an empty cache. So far, I'm not able to reproduce the crashing on the new profile. Unfortunately, I have about a half-dozen extensions that have at least some configuration that isn't synchronized anywhere else, so I need to go back to 83 and the old profile, dump/export/backup all their settings to a file (or take notes), then go back to 87 and the new profile and restore/import/apply all those settings in the new profile. All my extensions were pulled down during the Google Sync and ran fine on 87 for roughly an hour -- that's twice as long as my longest browser session for version 87 on the old profile. I still convinced this is a bug -- nothing in my profile should cause a SEGV, ref_count violation, or corrupted double-linked list. But, there's at least a workaround, that I'm going to take advantage of, to create a new, blank profile and either sync or manually import (or likely a combination of both) all your settings into the new profile. It's not going to be a kind experience for people upgrading from buster to bullseye, especially since the crashes make it hard to export settings from your old profile. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) Twitter: @DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Bug#977901: chromium: Inconsistent SEGV
On Tue, 22 Dec 2020 23:43:23 +0100 Michel Le Bihan wrote: > Installing `chromium-dbgsym` should be enough. Please run Chromium with > the `--debug` flag like: `chromium --debug`. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963711#10 Chromium crashes on startup if I use the "-g" or "--debug" options. After I issue a "run" at the "(gdb)" prompt, there's some time (a few seconds), but I never get a GUI window and then it crashes. I do get a usable back trace for the crash on startup, which I added to that bug. > I was not able to reproduce those crashes. That's unfortunate. I'm up to 50 just today. I'm probably going to have to downgrade to 83 at least until there's another update. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) Twitter: @DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Bug#608220: hugs98: FTBFS (sort of): Socket.hsc: error: invalid application of 'sizeof' to incomplete type 'struct ucred'
In <201012291227.36061.mindboosterno...@gmail.com> (Message #10), Marcos Marado wrote: >Couldn't this be something similar to this one? >http://trac.haskell.org/network/ticket/20 Looks very similar. I wasn't able to look at the linked patch because the URL now gives a 404. Perhaps the patch can be retrieved from the history of GHC v6.11..v6.12. In <20101231161502.gy14...@debian.org> (Message #15), Cyril Brulebois wrote: >This seems to go away once the attached patch applied. I'm a bit concerned about automatically adding _GNU_SOURCE to the compiler flags. I know I've got a few programs banging around that fail to compile when that is applied, because they requires the POSIX version of strerror_r. In particular, this could change the results of previous AC_COMPILE tests. Does the patch work without the nested AC_COMPILE_IFELSE? If not, I'd say apply and fix any potential fallout later. Otherwise, it would be good to drop it. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Bug#607988: Confirmation
Just wanted to confirm that I have seen this on both my systems where I've upgraded to the Squeeze version of the python package. Most of the dangling symlinks were in /usr/lib/python2.6/dist-packages/reportlab, but I believe there were a few others that had to be removed from /usr/lib/python2.6/dist- packages. The package(s) that created the symlinks should be responsible for removing them, but I think the patch provided by Mr. Dreimann (or something similar) should be applied to prevent the package upgrade failures. (Any dpkg error is rather intimidating to new users.) -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Bug#532065: java-gcj-compat-dev failure to install
In <200906081535.31671.dschep...@gmail.com>, Daniel Schepler wrote: >The problem is that neither gcj, gcj-jdk, nor java-gcj-compat-dev depends > on gcj-4.3 anymore. An "apt-get install default-jdk-builddep gcj-4.3" > works fine in a chroot. So it should be enough just to add gcj-4.3 as a > dependency of one of those packages. Stable gcj: Version: 4:4.3.2-2 Depends: cpp (>= 4:4.3.2-2), gij (>= 4:4.3.2-2), gcj-4.3 (>= 4.3.2-1) Testing gcj: Version: 4:4.3.3-5 Depends: cpp (>= 4:4.3.3-5), gij (>= 4:4.3.3-5), gcj-4.3 (>= 4.3.3-2) Unstable gcj-jdk: Version: 4:4.3.3-9 Depends: libgcj-common (>= 1:4.4.0-7), gcj-jre (>= 4:4.3.3-9), java-gcj-compat-dev (>= 1.0.80), gcj-4.3 (>= 4.3.3-2) No matter what flavor you are pulling from gcj+gcj-jdk should Depend on gcj-4.3. So, the quoted diagnosis is surely wrong. I think instead that default-jdk is missing a Depend on gcj-jdk OR java-gcj-compat-dev is missing a Depend on gcj-jdk. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Bug#489593: Can I haz stack frames plz?
Once you get the SIGSEGV in gdb, please use the bt command to produce a full backtrace. Before generating another backtrace, please install http://packages.debian.org/lenny/libc6-dbg if possible. (Not sure if it will work with ldconfig broken.) Thank you for your effort so far. -- Boyd Stephen Smith Jr. ,= ,-_-. =. [EMAIL PROTECTED] ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.org/ \_/ signature.asc Description: This is a digitally signed message part.
