On Wed, 19 May 2004, Andrew Suffield wrote: > On Tue, May 18, 2004 at 11:04:46AM +0200, Juraj Bednar wrote: > > 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. > > > > > > (of course I can not do stack trace at this point, gdb says "No stack"). > > This should not be an "of course". This should not happen at all. How > did this happen? You *should* be looking at a process frozen in T > state, and be able to examine its stack with gdb at this point.
The top-level dpkg program still exists, but the sub-process that dpkg forks(of itself) is what caused the signal. I bet gdb is not following forks correctly.
