[comp.unix.ultrix] very strange dbx behavior on ultrix 4.0, ds 5000/200

mao@eden.Berkeley.EDU (Mike Olson) (05/23/91)

it's unlikely that anyone can offer a fix for this, but can anyone explain
what is going on?  here's the short scenario:  i have a structure that
contains four doubles.  i call a function in my program to print its contents.
this works correctly.  however, if i set a breakpoint at that function call
in dbx, and call the function by hand, i get garbage.

here's some sample code:

	#include <stdio.h>

	typedef struct bug {
		double a, b, c, d;
	} bug;

	main()
	{
		bug *x;

		x = (bug *) malloc(sizeof(bug));
		x->a = 1.0;
		x->b = 2.0;
		x->c = 3.0;
		x->d = 4.0;

		showbug(x);
	}

	showbug(x)
		bug *x;
	{
		printf("0x%lx:(%g,%g,%g,%g)\n", x, x->a, x->b, x->c, x->d);
	}

and a script of a terminal session showing the bug:

	Script started on Wed May 22 11:54:44 1991
	% cc -g -o dbxbug dbxbug.c
	% dbx dbxbug
	dbx version 2.0
	Type 'help' for help.
	reading symbolic information ...
	main:  11  x = (bug *) malloc(sizeof(bug));
	(dbx) stop at "dbxbug.c":17
	[2] stop at "dbxbug.c":17
	(dbx) r
	[2] stopped at   [main:17 ,0x400244] 	showbug(x);
	(dbx) down 0
	main:  17  showbug(x);
	(dbx) func showbug(x)
---->	0x10002000:(5.29981e-315,5.30499e-315,5.30758e-315,1.7809e-307)
	main:  17  showbug(x);
	(dbx) c
---->	0x10002000:(1,2,3,4)

	Program terminated normally
	(dbx) q

you'll notice at the first arrow that i call showbug() by hand with the
proper parameter.  it gets the right argument, as you can see by looking
at the address it prints: 0x10002000.  the structure contents are trash.
however, when i let the compiled code do the call, the results are correct
-- structure's at the same address, called from the same line in the source
code, with different results.  by the way, i did a memory dump before my
manual call to showbug and after the compiled one -- the memory pointed to
by x is the same in both cases.  for brevity, i did not include that dump
above.

i should know better than to trust dbx on ultrix 4.0 by now, but this one
is pretty heinous.  can anyone tell me what is happening?

					mike olson
					postgres research group
					uc berkeley
					mao@postgres.berkeley.edu