[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#200351: This bug is also triggered by no command-line options at all.



This bug is also triggered by just calling "dpkg" with no options
at all. (Though correct options work like expected, when there are
no user errors.)

Following a gdb session on my mips machine:

GNU gdb 5.3.90_2003-08-24-cvs-debian
Copyright 2003 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 "mips-linux"...
(gdb) b main
Breakpoint 1 at 0x4054ac: file /home/chroot/dpkg/dpkg-1.10.10/main/main.c, line 551.
(gdb) r
Starting program: /home/chroot/dpkg/dpkg-1.10.10/build/main/dpkg 

Breakpoint 1, main (argc=1, argv=0x0)
    at /home/chroot/dpkg/dpkg-1.10.10/main/main.c:551
551	  standard_startup(&ejbuf, argc, &argv, DPKG, 1, cmdinfos);
(gdb) n
547	int main(int argc, const char *const *argv) {
(gdb) n
551	  standard_startup(&ejbuf, argc, &argv, DPKG, 1, cmdinfos);
(gdb) n
547	int main(int argc, const char *const *argv) {
(gdb) n
551	  standard_startup(&ejbuf, argc, &argv, DPKG, 1, cmdinfos);
(gdb) n
552	  if (!cipaction) badusage(_("need an action option"));
(gdb) n
551	  standard_startup(&ejbuf, argc, &argv, DPKG, 1, cmdinfos);
(gdb) n
552	  if (!cipaction) badusage(_("need an action option"));
(gdb) n
0x004055cc	563	  return reportbroken_retexitstatus();
(gdb) s
badusage (fmt=0x7fff7890 "")
    at /home/chroot/dpkg/dpkg-1.10.10/lib/ehandle.c:259
259	void badusage(const char *fmt, ...) {
(gdb) n
265	  snprintf(errmsgbuf,sizeof(errmsgbuf),"%s\n\n%s", buf, gettext(printforhelp));
(gdb) n
263	  vsnprintf(buf,sizeof(buf), fmt,al);
(gdb) n
265	  snprintf(errmsgbuf,sizeof(errmsgbuf),"%s\n\n%s", buf, gettext(printforhelp));
(gdb) n
267	  longjmp(*econtext->jbufp,1);
(gdb) n
266	  errmsg= errmsgbuf; 
(gdb) n
267	  longjmp(*econtext->jbufp,1);
(gdb) p econtext
$1 = (struct errorcontext * volatile) 0x1000d320
(gdb) p *econtext
$2 = {next = 0x0, jbufp = 0x7fff7cc0, cleanups = 0x0, 
  printerror = 0x423320 <print_error_fatal>, contextstring = 0x0}
(gdb) bt
#0  badusage (fmt=0x7fff7cc0 "")
    at /home/chroot/dpkg/dpkg-1.10.10/lib/ehandle.c:267
#1  0x00405608 in main (argc=2147450048, argv=0x7fff7e18)
    at /home/chroot/dpkg/dpkg-1.10.10/main/main.c:563
(gdb) s

Program received signal SIGBUS, Bus error.
0x0042aebc in standard_startup (ejbuf=0x7fff7cc0, argc=1, argv=0x42f650, 
    prog=0x2 <Address 0x2 out of bounds>, loadcfg=1, cmdinfos=0x100000e0)
    at /home/chroot/dpkg/dpkg-1.10.10/lib/startup.c:47
47	  if (setjmp(*ejbuf)) { /* expect warning about possible clobbering of argv */
(gdb) bt
#0  0x0042aebc in standard_startup (ejbuf=0x7fff7cc0, argc=1, argv=0x42f650, 
    prog=0x2 <Address 0x2 out of bounds>, loadcfg=1, cmdinfos=0x100000e0)
    at /home/chroot/dpkg/dpkg-1.10.10/lib/startup.c:47

    GDB is unable to find the start of the function at 0x2ad09570
and thus can't determine the size of that function's stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
    This problem is most likely caused by an invalid program counter or
stack pointer.
    However, if you think GDB should simply search farther back
from 0x2ad09570 for code which looks like the beginning of a
function, you can increase the range of the search using the `set
heuristic-fence-post' command.
(gdb) c
Continuing.

Program terminated with signal SIGBUS, Bus error.
The program no longer exists.
(gdb) q

Hochachtungsvoll,
	Bernhard R. Link
                
P.S: I'm also experiencing a bus error or segmentation fault with
things like:
echo "foo wrongword" | dpkg --set-selections
while things like 
echo "foo install" | dpkg --set-selections
works, but only within an chroot and not in the hosting system.
This may or not may be an different error, but this bug here makes
debuging the other one quite difficult.
                



Reply to: