PR# 14548 Incomplete stack trace

Problem Report Summary
Submitter: randyjohn
Category: Runtime
Priority: Medium
Date: 2008/06/30
Class: Bug
Severity: Serious
Number: 14548
Release: 6.2.7.3753
Confidential: No
Status: Closed
Responsible: ted_eiffel
Environment: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; WOW64; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; InfoPath.1; .NET CLR 3.0.04506.648)
Synopsis: Incomplete stack trace

Description
The feature EXCEPTION.trace doesn't deliver the full trace anymore.  It should deliver everything from the point of the error, down to the creation of the root.  Instead, it delivers from the point of the error, down to the first rescue clause.  By the way, I was using two rescue clauses.  (I tried this in 5.7.64493 and it displays down to the rescue clause that is currently calling 'exception_trace' - each rescue clause gives a different result).  I'm pretty sure that this worked once upon a time.  If Zoran can get me a 5.6 compiler going, I'll try it.  This is pretty important to us.  We place these traces in emails and log files and we REALLY want to see the full trace.
   Randy
To Reproduce
class ROOT

inherit
	MEMORY
	EXCEPTIONS

create
	make

feature

	make is
	do
		foo1
	end

	foo1 is
	do
		foo2
	rescue
		print("Start of foo1 rescue.%N")
		print(exception_trace)
		print("End of foo1 rescue.%N")
	end

	foo2 is
	do
		foo3
	rescue
		print("Start of foo2 rescue.%N")
		print(exception_trace)
		print("End of foo2 rescue.%N")
	end

	foo3 is
	do
		foo4
--	rescue
--		print("Start of foo3 rescue.%N")
--		print(exception_trace)
--		print("End of foo3 rescue.%N")
	end

	foo4 is
	do
		foo5
	rescue
		print("Start of foo4 rescue.%N")
		print(exception_trace)
		print("End of foo4 rescue.%N")
	end

	foo5 is
	local
		l_string: STRING
	do
		l_string.do_nothing
--	rescue
--		print("Start of foo5 rescue.%N")
--		print(exception_trace)
--		print("End of foo5 rescue.%N")
	end

end
Problem Report Interactions
From:ted_eiffel    Date:2008/08/11    Status: Closed    Download   
This has been fixed in rev#74391. Thank you for reporting.

From:manus_eiffel    Date:2008/07/01    Status: Analyzed    Download   
I was going to answer that indeed this behavior has always existed. I agree with you that it should go to either the root creation procedure of the main thread, or the thread creation procedure for the other threads.

From:randyjohn    Date:2008/07/01    Download   
Well, I'm really confused now.  Version 5.6.1218 isn't any better.  Maybe this is a feature request.
   Randy