On Tue, 2004-05-18 at 11:04 +0200, Juraj Bednar wrote: > > If you run without the -D does it still segfault? > > of course, I added -D just after I found it segfaults so it has some > debugging output. > It's segfaulting on a large number of different packages? Are these packages constant or is it random which it will and won't segfault on. Have you tried higher debugging output? > > How much memory does your system have? > > 256MB + 1GB swap, when doing it, at least 40MB of memory is free and > 900MB of swap space is free too. > I assume you mean 40MB is free before buffers and cache are deducted? > > Run after "ulimit -c unlimited", then using gdb and the resulting core > > file can you send trace information? > > it does not dump core even after this command, I really don't know why. > You're not getting core dumps?! > Running dpkg straight from gdb: > > (gdb) run -i /var/cache/apt/archives/libnewt0.51_0.51.6-3_i386.deb > Starting program: /usr/bin/dpkg -i /var/cache/apt/archives/libnewt0.51_0.51.6-3_i386.deb > (no debugging symbols found)...(no debugging symbols found)...(no > debugging symbols found)... > (Reading database ... 26414 files and directories currently installed.) > Preparing to replace libnewt0.51 0.51.4-23 (using > .../libnewt0.51_0.51.6-3_i386.deb) ... > Unpacking replacement libnewt0.51 ... > (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... > Program terminated with signal SIGSEGV, Segmentation fault. > The program no longer exists. > This can't happen... gdb should have a stopped application to trace. I'm going to suggest there's something seriously broken in your system; what kind of temperature is it running at? Have you tried the same drive in a different machine, or perhaps different RAM chips in your machine? Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist?
Attachment:
signature.asc
Description: This is a digitally signed message part