Bug#249567: dpkg: Dpkg -i segfaults for package dpkg and libnewt0
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.
Reply to: