[9fans] debugging help asked for

[9fans] debugging help asked for

[cej]

[-- Attachment #1: Type: text/plain, Size: 446 bytes --]

Dear folks!

 

I compiled successfully a code ported from gcc/linux that runs OK there. However, I'm getting stack underflow error when running it under Plan 9.

The code is here:

 

http://www.gli.cas.cz/home/cejchan/plan9/pathd8.tgz

 

to run:

 

pathd8 infile outfile

 

Any hints much appreciated!! I cant't see why zeros are read in within the second cycle [see print()]

Thanks, regards,

 

++pac.

 


[-- Attachment #2: Type: text/html, Size: 3683 bytes --]

Re: [9fans] debugging help asked for

[Richard Miller]

You're dividing by zero in pathd8/mpl.c:

      subtree_var[i] =  n->child[i]->var + n->edge_len[i];
      ...
      p_bar_numerator += subtree_est[i]/subtree_var[i];

because the terminal node 'Frog' has var and edge_len
both equal to zero.

Possibly gcc/linux reacts differently to division by zero?

Re: [9fans] debugging help asked for

[Charles Forsyth]

> I compiled successfully a code ported from gcc/linux that runs OK there. However, I'm getting stack underflow error when running it under Plan 9.

that often happens when a function that returns double has no external declaration in scope where it's used,
and it gets the default type of int, so the result on the floating-point stack is not popped at the point of call.
that applies even when it's called for side-effect.

double	f(int);

void
g(void)
{
	f(3);
}

h% 8c -S db.c
	TEXT	g+0(SB),0,$8
	MOVL	$3,AX
	MOVL	AX,(SP)
	CALL	,f+0(SB)
	FMOVDP	F0,F0
	RET	,
	END	,

note the P (pop) suffix on FMOVDP

of course, the compiler will have complained about the missing
declaration unless you've told it otherwise.

Re: [9fans] debugging help asked for

[Charles Forsyth]

>> I compiled successfully a code ported from gcc/linux that runs OK there. However, I'm getting stack underflow error when running it under Plan 9.
> 
> that often happens when a function that returns double has no external declaration in scope where it's used,

hang on: perhaps that only causes stack overflow.  oh well, now you know not to do it in any case.

Re: [9fans] debugging help asked for

[Charles Forsyth]

>> that often happens when a function that returns double has no external declaration in scope where it's used,
> 
> hang on: perhaps that only causes stack overflow.  oh well, now you know not to do it in any case.

i've checked now: that case does give stack overflow.

stack underflow will result if you declare a function as returning double in the caller, but it doesn't actually do that,
perhaps it's void or int.