gobo-eiffel-develop — Development discussions

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Eric B. <er...@go...>]

Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     Eric> Colin Paul Adams wrote:
>     >>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
>     >> 
>     Eric> Was it with the same version of the Boehm GC?
>     >> 
>     >> So I just tried with 6.7, using the same configuration options
>     >> that "cured" the original problem with 7.0.
>     >> 
>     >> I am still getting the original problem with 6.7.
> 
>     Eric> Does the "original problem" print "Unhandled exception"?
> 
> Yes.
> 
> The original problem occurs when running a particular test case, or
> indeed any test case that I tried that occurs physically later in the
> test catalog (an xml file).
> 
> This appears to have been fixed with the 7.0 collector, when I added
> the additional configuration options. But then the problem still
> occurs if I run all the test cases (so it may just be that a greater
> memory burden is triggering it).

What I didn't get yet is an execution trace of the problem where
"unhandled exception" is printed. For that, I would need the trace
at the point when GE_raise is first called. Last time you tried it,
it was something like that:

~~~~~~~~~~~~~~~~~
But it doesn't break there:

(gdb) break GE_raise
Breakpoint 1 at 0x9afba75: file gestalt_test_driver48.c, line 24535.
(gdb) run
Starting program: /home/colin/gestalt/test/gestalt_test_driver 
--case=accessor20_018_01
[Thread debugging using libthread_db enabled]
[New Thread -1209092400 (LWP 17574)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1209092400 (LWP 17574)]
GC_clear_fl_links (flp=0xb84ee50) at reclaim.c:469
469            *flp = 0;
(gdb)
(gdb) backtrace
#0  GC_clear_fl_links (flp=0xb84ee50) at reclaim.c:469
#1  0x09b02382 in GC_start_reclaim (report_if_found=0) at reclaim.c:504
#2  0x09b05c47 in GC_finish_collection () at alloc.c:680
#3  0x09b09415 in GC_alloc_large (lb=3016, k=1, flags=0) at malloc.c:53
#4  0x09b09719 in GC_generic_malloc (lb=3015, k=1) at malloc.c:171
#5  0x09b098ba in GC_core_malloc (lb=3015) at malloc.c:286
#6  0x0804ace6 in GE_ms (
     s=0x9b50518 
"%G?%@\204\215%G??%@\210%G??%@\210%G??%@\210%G??%@\210%G??%@\210%G??%@\210%G??%@\210%G??%@\210%G??%@\210%G??%@\210%G??%@\210%G??%@\210%G??%@\210%G??%@\210%G??%@\210%G??%@\210%G??%@\210%G??%@\210%G??%@\210%G??%@\210%G??%@\210%G??%@\210%G??%@\210%G??%@\210%G??%@\210%G??%@\210%G??%@\210%G?%@\204\215$(CBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBe%G?%@(B\204\215%G??%@\200%G??%@\200%G??%@\200%G??%@\200%G??%@\200%G??%@\200%G??%@\200%G??%@\200%G??%@\200%G??%@"..., 
c=3003) at gestalt_test_driver1.c:1882
#7  0x09afa725 in GE_const_init () at gestalt_test_driver48.c:21933
#8  0x09afba25 in main (argc=Cannot access memory at address 0x0
) at gestalt_test_driver48.c:24448
(gdb)
~~~~~~~~~~~~~~~~~~~~~~~~~


-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Colin P. A. <co...@co...>]

>>>>> "Eric" == Eric Bezault <er...@go...> writes:

    Eric> Colin Paul Adams wrote:
    >> When running under the gdb I get:
    >> 
    >> Call on Void target!  [Switching to Thread -1208531248 (LWP
    >> 755)]
    >> 
    >> Breakpoint 1, GE_raise (code=1) at
    >> gestalt_test_driver48.c:24535 24535 GE_rescue* r =
    >> GE_last_rescue; (gdb)
    >> 
    >> (gdb) backtrace #0 GE_raise (code=1) at
    >> gestalt_test_driver48.c:24535 #1 0x09afbe26 in GE_check_void
    >> (obj=0x0) at gestalt_test_driver48.c:24608 #2 0x08bc2571 in
    >> T1480f305 (ac=0xbfc2dfcc, C=0xb817540, a1=0xb447cb0) at
    >> gestalt_test_driver20.c:27100

    Eric> This does not make sense to me. The C function T1480f305
    Eric> corresponds to XM_XPATH_IDREF.create_node_iterator, which
    Eric> looks like that:

    Eric> 	create_node_iterator (a_context: XM_XPATH_CONTEXT) is
    Eric> -- Create an iterator over a node sequence do todo
    Eric> ("create_node_iterator", False) end

    Eric> I don't see how there could be a call-on-void-target in that
    Eric> routine, there is no qualified call!

Ah. There is as of yesterday (I went through all the remaining todos,
and eliminated all those that were not for a possible future
schema-aware version of XSLT)!

Here is the newer routine:

	create_node_iterator (a_context: XM_XPATH_CONTEXT) is
			-- Create iterator over nodes of a sequence.
		local
			l_idrefs: DS_ARRAYED_LIST [STRING]
			l_node: XM_XPATH_NODE
			l_splitter: ST_SPLITTER
			l_iterator: XM_XPATH_SEQUENCE_ITERATOR [XM_XPATH_NODE]
			l_result: DS_CELL [XM_XPATH_ITEM]
		do
			last_node_iterator := Void
			create l_result.make (Void)
			arguments.item (2).evaluate_item (l_result, a_context)
			if l_result.item.is_error then
				create {XM_XPATH_INVALID_NODE_ITERATOR} last_node_iterator.make (l_result.item.error_value)
			else
				check
					node: l_result.item.is_node
					-- `required_type' will have ensured this
				end
				l_node := l_result.item.as_node.root
				if l_node.is_document then
					arguments.item (1).create_node_iterator (a_context)
					if arguments.item (1).last_node_iterator.is_error then
						last_node_iterator := arguments.item (1).last_node_iterator
					else
						create l_idrefs.make_default
						l_idrefs.set_equality_tester (string_equality_tester)
						l_iterator := arguments.item (1).last_node_iterator
						from l_iterator.start until l_iterator.is_error or else l_iterator.after loop
							create l_splitter.make
							l_idrefs.append_last (l_splitter.split (l_iterator.item.string_value))
							l_iterator.forth
						end
						if l_iterator.is_error then
							last_node_iterator := l_iterator
						else
							last_node_iterator := l_node.as_document.idrefs_nodes (l_idrefs)
						end
					end
				else
					create {XM_XPATH_INVALID_NODE_ITERATOR} last_node_iterator.make_from_string ("In the idref() function," +
						" the tree being searched must be one whose root is a document node", Xpath_errors_uri, "FODC0001", Dynamic_error)
				end
			end
		end

In the line:

if l_result.item.is_error then

l_result.item should be guarenteed non-Void due to XPath static
typing.

I'll run the gobo test cases, and if they all pass, I'll check in my changes.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Eric B. <er...@go...>]

Colin Paul Adams wrote:
> When running under the gdb I get:
> 
> Call on Void target!
> [Switching to Thread -1208531248 (LWP 755)]
> 
> Breakpoint 1, GE_raise (code=1) at gestalt_test_driver48.c:24535
> 24535           GE_rescue* r = GE_last_rescue;
> (gdb) 
> 
> (gdb) backtrace
> #0  GE_raise (code=1) at gestalt_test_driver48.c:24535
> #1  0x09afbe26 in GE_check_void (obj=0x0) at gestalt_test_driver48.c:24608
> #2  0x08bc2571 in T1480f305 (ac=0xbfc2dfcc, C=0xb817540, a1=0xb447cb0)
>     at gestalt_test_driver20.c:27100

This does not make sense to me. The C function T1480f305 corresponds to
XM_XPATH_IDREF.create_node_iterator, which looks like that:

	create_node_iterator (a_context: XM_XPATH_CONTEXT) is
			-- Create an iterator over a node sequence
		do
			todo ("create_node_iterator", False)
		end

I don't see how there could be a call-on-void-target in that
routine, there is no qualified call!

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Colin P. A. <co...@co...>]

>>>>> "Eric" == Eric Bezault <er...@go...> writes:

    Eric> Colin Paul Adams wrote:
    >>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
    >> 
    Eric> Was it with the same version of the Boehm GC?
    >> 
    >> So I just tried with 6.7, using the same configuration options
    >> that "cured" the original problem with 7.0.
    >> 
    >> I am still getting the original problem with 6.7.

    Eric> Does the "original problem" print "Unhandled exception"?

Yes.

The original problem occurs when running a particular test case, or
indeed any test case that I tried that occurs physically later in the
test catalog (an xml file).

This appears to have been fixed with the 7.0 collector, when I added
the additional configuration options. But then the problem still
occurs if I run all the test cases (so it may just be that a greater
memory burden is triggering it).

I'm now trying the CVS version of the gc.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Eric B. <er...@go...>]

Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     Eric> Was it with the same version of the Boehm GC?
> 
> So I just tried with 6.7, using the same configuration options that
> "cured" the original problem with 7.0.
> 
> I am still getting the original problem with 6.7.

Does the "original problem" print "Unhandled exception"?

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Colin P. A. <co...@co...>]

>>>>> "Eric" == Eric Bezault <er...@go...> writes:

    Eric> Was it with the same version of the Boehm GC?

So I just tried with 6.7, using the same configuration options that
"cured" the original problem with 7.0.

I am still getting the original problem with 6.7.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Colin P. A. <co...@co...>]

>>>>> "Eric" == Eric Bezault <er...@go...> writes:

    Eric> Colin Paul Adams wrote:
    >>>>>>> "Colin" == Colin Adams <col...@go...>
    >>>>>>> writes:
    >> 
    >> >> I'm also aving a go and trying to reproduce the original >>
    >> problem on Windows.
    >> 
    >> It didn't occur on Windows.

    Eric> So, it means that the problem with Void is probably not due
    Eric> to a limitation in gec.

I don't yet feel confident about concluding anything from the problem
not occuring under windows because:

1) There is more memory on the citrix server that I tried the test on
under windows.
2) The full tests can't be run under windows (at the moment)
3) There was no problem under Linux two weeks ago, and I have yet to
work out what might have changed.

    Eric> with the GC, it thinks that there is no more memory and
    Eric> 'GC_malloc' returns a null pointer (i.e. Void
    Eric> object). Currently gec does not raise yet a "no more memory"
    Eric> exception in this case.  So a creation instruction would
    Eric> silently return a Void reference.

How soon could you change gec to raise "no more memory"? I would think
its definietly worth trying to confirm that this is what is happening.

    Eric> Anyway, there seems to be problems with the Boehm GC under
    Eric> Linux. As I said in a previous message, perhaps there are
    Eric> some options to be used to compile the Boehm GC that would
    Eric> work around these problems. But who knows which options to
    Eric> try?

I'll keep trying things.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Eric B. <er...@go...>]

Colin Paul Adams wrote:
>>>>>> "Colin" == Colin Adams <col...@go...> writes:
> 
>     >> I'm also aving a go and trying to reproduce the original
>     >> problem on Windows.
> 
> It didn't occur on Windows.

So, it means that the problem with Void is probably not due to
a limitation in gec. It could be that because of problems with
the GC, it thinks that there is no more memory and 'GC_malloc'
returns a null pointer (i.e. Void object). Currently gec
does not raise yet a "no more memory" exception in this case.
So a creation instruction would silently return a Void
reference.

Anyway, there seems to be problems with the Boehm GC under
Linux. As I said in a previous message, perhaps there are
some options to be used to compile the Boehm GC that would
work around these problems. But who knows which options
to try?

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Colin P. A. <co...@co...>]

>>>>> "Eric" == Eric Bezault <er...@go...> writes:

    >> But it's strange - the program was definitely working two weeks
    >> ago.

    Eric> Was it with the same version of the Boehm GC?

Hm. No. It was 6.7 and I'm using 7.0 now. I might try with 6.7 again.

The original problem occured with both versions though, and that
wasn't happening two weeks ago either.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Colin P. A. <co...@co...>]

>>>>> "Colin" == Colin Adams <col...@go...> writes:

    >> I'm also aving a go and trying to reproduce the original
    >> problem on Windows.

It didn't occur on Windows.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Eric B. <er...@go...>]

Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     Eric> In order to make sense out of this execution trace I would
>     Eric> need to have a look at the generated .h file, so that we can
>     Eric> translate the generated C function names to the
>     Eric> corresponding Eiffel feature names. How big is this file?
> 
> 9917679 bytes.
> 
> Shall I send it by private email?

Yes, you can send a compressed version.

>     Eric> Either the call-on-void-target is real, or some
>     Eric> not-yet-implemented parts of gec that can trigger this wrong
>     Eric> behaviors are:
> 
>     Eric> * use of user-defined expanded classes 
>     Eric> * call to external
>     Eric> routines returning an object whose type is not a basic
>     Eric> expanded type or STRING.
> 
> I guess eposix might be returning either of those.
> 
> But it's strange - the program was definitely working two weeks ago.

Was it with the same version of the Boehm GC?

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Colin P. A. <co...@co...>]

>>>>> "Eric" == Eric Bezault <er...@go...> writes:

    Eric> In order to make sense out of this execution trace I would
    Eric> need to have a look at the generated .h file, so that we can
    Eric> translate the generated C function names to the
    Eric> corresponding Eiffel feature names. How big is this file?

9917679 bytes.

Shall I send it by private email?

    Eric> Either the call-on-void-target is real, or some
    Eric> not-yet-implemented parts of gec that can trigger this wrong
    Eric> behaviors are:

    Eric> * use of user-defined expanded classes 
    Eric> * call to external
    Eric> routines returning an object whose type is not a basic
    Eric> expanded type or STRING.

I guess eposix might be returning either of those.

But it's strange - the program was definitely working two weeks ago.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Eric B. <er...@go...>]

Colin Paul Adams wrote:
>>>>>> "Colin" == Colin Paul Adams <co...@co...> writes:
> 
> 
>     Colin> So I tried the following options:
> 
>     Colin> ./configure --enable-large-config --enable-gc-debug
>     Colin> --enable-gc-assertions --prefix=/usr/local
> 
>     Colin> but now the problem no longer occurs in the original case.
> 
>     Colin> However, it is still crashing further on:
> 
>     Colin> 'stack_trace_string' in 'eif_except.h' not implemented Call
>     Colin> on Void target!  Unhandled exception
> 
>     Colin> Perhaps this is a different problem.
> 
> When running under the gdb I get:
> 
> Call on Void target!
> [Switching to Thread -1208531248 (LWP 755)]
> 
> Breakpoint 1, GE_raise (code=1) at gestalt_test_driver48.c:24535
> 24535           GE_rescue* r = GE_last_rescue;
> (gdb) 
> 
> (gdb) backtrace
> #0  GE_raise (code=1) at gestalt_test_driver48.c:24535
> #1  0x09afbe26 in GE_check_void (obj=0x0) at gestalt_test_driver48.c:24608
> #2  0x08bc2571 in T1480f305 (ac=0xbfc2dfcc, C=0xb817540, a1=0xb447cb0)
>     at gestalt_test_driver20.c:27100

In order to make sense out of this execution trace I would
need to have a look at the generated .h file, so that we can
translate the generated C function names to the corresponding
Eiffel feature names. How big is this file?

Either the call-on-void-target is real, or some not-yet-implemented
parts of gec that can trigger this wrong behaviors are:

* use of user-defined expanded classes
* call to external routines returning an object whose type
   is not a basic expanded type or STRING.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Eric B. <er...@go...>]

Colin Adams wrote:
>> I'm also aving a go and trying to reproduce the original problem on Windows.
> 
> On windows, when I compile I see:
> 
> [VCCH-1] class KL_DIRECTORY (17,2): class is not marked as deferred
> but has deferred feature `there_exists'.
> 
> [VGCP-1] class KL_DIRECTORY (50,2): deferred class has a creation clause.

Go to $GOBO\library\kernel and run 'geant install'.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Colin P. A. <co...@co...>]

>>>>> "Colin" == Colin Paul Adams <co...@co...> writes:


    Colin> So I tried the following options:

    Colin> ./configure --enable-large-config --enable-gc-debug
    Colin> --enable-gc-assertions --prefix=/usr/local

    Colin> but now the problem no longer occurs in the original case.

    Colin> However, it is still crashing further on:

    Colin> 'stack_trace_string' in 'eif_except.h' not implemented Call
    Colin> on Void target!  Unhandled exception

    Colin> Perhaps this is a different problem.

When running under the gdb I get:

Call on Void target!
[Switching to Thread -1208531248 (LWP 755)]

Breakpoint 1, GE_raise (code=1) at gestalt_test_driver48.c:24535
24535           GE_rescue* r = GE_last_rescue;
(gdb) 

(gdb) backtrace
#0  GE_raise (code=1) at gestalt_test_driver48.c:24535
#1  0x09afbe26 in GE_check_void (obj=0x0) at gestalt_test_driver48.c:24608
#2  0x08bc2571 in T1480f305 (ac=0xbfc2dfcc, C=0xb817540, a1=0xb447cb0)
    at gestalt_test_driver20.c:27100
#3  0x08b1a213 in T1480f304 (ac=0xbfc2e094, C=0xb817540, a1=0xb447cb0)
    at gestalt_test_driver19.c:24724
#4  0x082d76ba in T405x18595T0 (ac=0xbfc2e094, C=0xb817540, a1=0xb447cb0)
    at gestalt_test_driver5.c:9242
#5  0x090b2b6e in T1453f295 (ac=0xbfc2e17c, C=0xb817460, a1=0xb79b1b0, 
    a2=0xb447cb0) at gestalt_test_driver27.c:3346
#6  0x082bf07f in T405x18593T0T0 (ac=0xbfc2e17c, C=0xb817460, a1=0xb79b1b0, 
    a2=0xb447cb0) at gestalt_test_driver4.c:70246
#7  0x08e91712 in T1939f277 (ac=0xbfc2e21c, C=0xb3a8630, a1=0xb79b1b0, 
    a2=0xb447cb0) at gestalt_test_driver24.c:12142
#8  0x082c04f2 in T405x18593T0T0 (ac=0xbfc2e21c, C=0xb3a8630, a1=0xb79b1b0, 
    a2=0xb447cb0) at gestalt_test_driver4.c:70691
#9  0x084a1562 in T1917f315 (ac=0xbfc2e280, C=0xb8fa888, a1=0xb447cb0)
    at gestalt_test_driver8.c:16433
#10 0x084a1190 in T1917f306 (ac=0xbfc2e35c, C=0xb8fa888, a1=0xb79b530, 
    a2=0xb447cb0) at gestalt_test_driver8.c:16378
#11 0x0831b762 in T2058x21241T0T0 (ac=0xbfc2e35c, C=0xb8fa888, a1=0xb79b530, 
    a2=0xb447cb0) at gestalt_test_driver5.c:38132
#12 0x084a1a74 in T1916f302 (ac=0xbfc2e3d8, C=0xb4394e0, a1=0xb79b530, 
---Type <return> to continue, or q <return> to quit---
    a2=0xb447cb0) at gestalt_test_driver8.c:16523
#13 0x08b45820 in T1916f303 (ac=0xbfc2e4ac, C=0xb4394e0, a1=0xb447cb0)
    at gestalt_test_driver20.c:1233
#14 0x082d5ce4 in T405x18597T0 (ac=0xbfc2e4ac, C=0xb4394e0, a1=0xb447cb0)
    at gestalt_test_driver5.c:8577
#15 0x084a33fe in T1913f316 (ac=0xbfc2e578, C=0xb8e7d20, a1=0xb79b630, 
    a2=0xb447cb0) at gestalt_test_driver8.c:16870
#16 0x0831b6b3 in T2058x21241T0T0 (ac=0xbfc2e578, C=0xb8e7d20, a1=0xb79b630, 
    a2=0xb447cb0) at gestalt_test_driver5.c:38118
#17 0x0845c525 in T393f13 (ac=0xbfc2e5d4, C=0xb7236c0, a1=0xb79b630, 
    a2=0xb447cb0) at gestalt_test_driver7.c:37402
#18 0x08460743 in T393f17 (ac=0xbfc2e66c, C=0xb7236c0, a1=0xb79b630, 
    a2=0xb50c370, a3=0xb447ee0) at gestalt_test_driver7.c:38480
#19 0x09229e4b in T317f91 (ac=0xbfc2e71c, C=0xb3c72d0, a1=0xb79b630, 
    a2=0xb3c72d0, a3=0xb3b99a0, a4=0xb799fc0, a5=0xb79b620, a6=0xb79b5b0, 
    a7=0xb447ee0) at gestalt_test_driver28.c:39758
#20 0x0922992d in T317f90 (ac=0xbfc2e784, C=0xb3c72d0, a1=0xb79b630, 
    a2=0xb8003e0, a3=0xb799fc0, a4=0xb79b620, a5=0xb79b5b0, a6=0xb447ee0)
    at gestalt_test_driver28.c:39700
#21 0x0922925f in T317f87 (ac=0xbfc2e884, C=0xb3c72d0, a1=0xb3b99a0)
    at gestalt_test_driver28.c:39593
#22 0x0922894a in T317f84 (ac=0xbfc2e9c4, C=0xb3c72d0, a1=0xb3b99a0, 
    a2=0xb723540) at gestalt_test_driver28.c:39480
---Type <return> to continue, or q <return> to quit---
#23 0x093711c0 in T317f77 (ac=0xbfc2ea94, C=0xb3c72d0, a1=0xb452d00, 
    a2=0xb723540) at gestalt_test_driver31.c:15574
#24 0x0936ffee in T276f81 (ac=0xbfc2ebc4, C=0xb8f0c00)
    at gestalt_test_driver31.c:15393
#25 0x0936fab7 in T276f69 (ac=0xbfc2ed08, C=0xb8f0c00)
    at gestalt_test_driver31.c:15328
#26 0x09366f93 in T27f163 (ac=0xbfc2ed7c, C=0xb2fff20, a1=0xb336108, a2=0x0, 
    a3=0xb549690) at gestalt_test_driver31.c:12610
#27 0x082b12e1 in T42x2196T0T0T0 (ac=0xbfc2ed7c, C=0xb2fff20, a1=0xb336108, 
    a2=0x0, a3=0xb549690) at gestalt_test_driver4.c:65029
#28 0x09366cb4 in T56f33p1 (ac=0xbfc2edc4, C=0xb2ce258, a1=0xb336108, a2=0x0, 
    a3=0xb549690) at gestalt_test_driver31.c:12569
#29 0x093666b8 in T56f33 (ac=0xbfc2ee2c, C=0xb2ce258, a1=0x0, a2=0x0, 
    a3=0xb549690) at gestalt_test_driver31.c:12441
#30 0x082b130d in T42x2196T0T0T0 (ac=0xbfc2ee2c, C=0xb2ce258, a1=0x0, a2=0x0, 
    a3=0xb549690) at gestalt_test_driver4.c:65031
#31 0x093665ad in T57f12p1 (ac=0xbfc2ee5c, C=0xb2cb4b0, a1=0x0, a2=0x0, 
    a3=0xb549690) at gestalt_test_driver31.c:12426
#32 0x09366544 in T57f12 (ac=0xbfc2eebc, C=0xb2cb4b0, a1=0x0, a2=0x0, 
    a3=0xb549690) at gestalt_test_driver31.c:12419
#33 0x082b1339 in T42x2196T0T0T0 (ac=0xbfc2eebc, C=0xb2cb4b0, a1=0x0, a2=0x0, 
    a3=0xb549690) at gestalt_test_driver4.c:65034
#34 0x0838dc8a in T62f250 (ac=0xbfc2fff8, C=0xb300e60, a1=0x0, a2=0x0, 
---Type <return> to continue, or q <return> to quit---
    a3=0xb549690) at gestalt_test_driver6.c:16743
#35 0x0832f3dd in T62f229 (ac=0xbfc3016c, C=0xb300e60, a1=169)
    at gestalt_test_driver5.c:42617
#36 0x083214c8 in T62f220 (ac=0xbfc301ac, C=0xb300e60)
    at gestalt_test_driver5.c:40165
#37 0x08320d54 in T62f216 (ac=0xbfc301f4, C=0xb300e60)
    at gestalt_test_driver5.c:40014
#38 0x0831d705 in T62f213 (ac=0xbfc3022c, C=0xb300e60)
    at gestalt_test_driver5.c:38654
#39 0x0831d644 in T62f207 (ac=0xbfc302d8, C=0xb300e60, a1=0xb2fd330)
    at gestalt_test_driver5.c:38641
#40 0x0831cacc in T27f152 (ac=0xbfc303cc, C=0xb2fff20)
    at gestalt_test_driver5.c:38399
#41 0x0831c649 in T21c13 (ac=0x0) at gestalt_test_driver5.c:38359
#42 0x09afbca1 in main (argc=Cannot access memory at address 0x15
) at gestalt_test_driver48.c:24452
(gdb) 

-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Colin A. <col...@go...>]

> I'm also aving a go and trying to reproduce the original problem on Windows.

On windows, when I compile I see:

[VCCH-1] class KL_DIRECTORY (17,2): class is not marked as deferred
but has deferred feature `there_exists'.

[VGCP-1] class KL_DIRECTORY (50,2): deferred class has a creation clause.

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Colin P. A. <co...@co...>]

>>>>> "Colin" == Colin Paul Adams <co...@co...> writes:

>>>>> "Eric" == Eric Bezault <er...@go...> writes:
    >>> But it doesn't break there:

    Eric> If it does not break here, then it means that it does not
    Eric> print "Unhandled exception", does it?

    Colin> Yes. I hadn't noticed that.

    Eric> It did not go very far. It is just creating the manifest
    Eric> constants.  It didn't even start the root creation procedure
    Eric> yet.

    Eric> As you can see, it looks like a bug in the GC. Or the GC is
    Eric> not configured correctly. Perhaps we need to compile it with
    Eric> another option than -DLARGE_CONFIG.

    Colin> It seems to behave differently when running under gdb.
    Colin> Maybe there is a speciall option needed in this case. I'll
    Colin> see if I can find anything. 

So I tried the following options:

./configure --enable-large-config --enable-gc-debug --enable-gc-assertions --prefix=/usr/local

but now the problem no longer occurs in the original case.

However, it is still crashing further on:

'stack_trace_string' in 'eif_except.h' not implemented
Call on Void target!
Unhandled exception

Perhaps this is a different problem.

I'm also aving a go and trying to reproduce the original problem on Windows. 
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Colin P. A. <co...@co...>]

>>>>> "Eric" == Eric Bezault <er...@go...> writes:

    >> But it doesn't break there:

    Eric> If it does not break here, then it means that it does not
    Eric> print "Unhandled exception", does it?

Yes. I hadn't noticed that.

    Eric> It did not go very far. It is just creating the manifest
    Eric> constants.  It didn't even start the root creation procedure
    Eric> yet.

    Eric> As you can see, it looks like a bug in the GC. Or the GC is
    Eric> not configured correctly. Perhaps we need to compile it with
    Eric> another option than -DLARGE_CONFIG.

It seems to behave differently when running under gdb.
Maybe there is a speciall option needed in this case. I'll see if I
can find anything.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Eric B. <er...@go...>]

Colin Paul Adams wrote:
>>>>>> "Colin" == Colin Paul Adams <co...@co...> writes:
> 
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
>     Eric> Colin Paul Adams wrote:
>     Eric> One other thing that I would be interested in, even if it
>     Eric> does not crash at the same location each time, is to know at
>     Eric> which stage in the execution trace the message "Unhandled
>     Eric> exception" is printed.  Could you try to put a break point
>     Eric> in the C code at the beginning of the C function 'GE_raise'
>     Eric> and see what the execution trace looks like?
>     >>> 
>     >>> How do I set a break point?
> 
>     Eric> I don't know. I guess it depends on the C debugger that is
>     Eric> available under Linux. Under Windows I do that from Visual
>     Eric> Studio.
> 
>     Colin> OK - I'm using gdb.
> 
>     Colin> I need to know which file to find GC_RAISE in. Is it part
>     Colin> of gec or boehm?  -- Colin Adams Preston Lancashire
> 
> Never mind - when i spelt it right, gdb found it.
> 
> But it doesn't break there:

If it does not break here, then it means that it does not
print "Unhandled exception", does it?

> (gdb) break GE_raise
> Breakpoint 1 at 0x9afba75: file gestalt_test_driver48.c, line 24535.
> (gdb) run
> Starting program: /home/colin/gestalt/test/gestalt_test_driver --case=accessor20_018_01
> [Thread debugging using libthread_db enabled]
> [New Thread -1209092400 (LWP 17574)]
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1209092400 (LWP 17574)]
> GC_clear_fl_links (flp=0xb84ee50) at reclaim.c:469
> 469            *flp = 0;
> (gdb) 
> (gdb) backtrace
> #0  GC_clear_fl_links (flp=0xb84ee50) at reclaim.c:469
> #1  0x09b02382 in GC_start_reclaim (report_if_found=0) at reclaim.c:504
> #2  0x09b05c47 in GC_finish_collection () at alloc.c:680
> #3  0x09b09415 in GC_alloc_large (lb=3016, k=1, flags=0) at malloc.c:53
> #4  0x09b09719 in GC_generic_malloc (lb=3015, k=1) at malloc.c:171
> #5  0x09b098ba in GC_core_malloc (lb=3015) at malloc.c:286
> #6  0x0804ace6 in GE_ms (
>     s=0x9b50518 "%G�%@\204\215%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G��%@\210%G�%@\204\215$(CBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBe%G�%@(B\204\215%G��%@\200%G��%@\200%G��%@\200%G��%@\200%G��%@\200%G��%@\200%G��%@\200%G��%@\200%G��%@\200%G��%@"..., c=3003) at gestalt_test_driver1.c:1882
> #7  0x09afa725 in GE_const_init () at gestalt_test_driver48.c:21933
> #8  0x09afba25 in main (argc=Cannot access memory at address 0x0
> ) at gestalt_test_driver48.c:24448
> (gdb) 

It did not go very far. It is just creating the manifest constants.
It didn't even start the root creation procedure yet.

As you can see, it looks like a bug in the GC. Or the GC is not
configured correctly. Perhaps we need to compile it with another
option than -DLARGE_CONFIG.

Perhaps I should try to plug with another GC. Any suggestion?
There is:

   http://www.hoard.org/

but it does not seem to have GC functionality.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Colin P. A. <co...@co...>]

>>>>> "Colin" =3D=3D Colin Paul Adams <co...@co...> writes:

>>>>> "Eric" =3D=3D Eric Bezault <er...@go...> writes:
    Eric> Colin Paul Adams wrote:
    Eric> One other thing that I would be interested in, even if it
    Eric> does not crash at the same location each time, is to know at
    Eric> which stage in the execution trace the message "Unhandled
    Eric> exception" is printed.  Could you try to put a break point
    Eric> in the C code at the beginning of the C function 'GE_raise'
    Eric> and see what the execution trace looks like?
    >>>=20
    >>> How do I set a break point?

    Eric> I don't know. I guess it depends on the C debugger that is
    Eric> available under Linux. Under Windows I do that from Visual
    Eric> Studio.

    Colin> OK - I'm using gdb.

    Colin> I need to know which file to find GC_RAISE in. Is it part
    Colin> of gec or boehm?  -- Colin Adams Preston Lancashire

Never mind - when i spelt it right, gdb found it.

But it doesn't break there:

(gdb) break GE_raise
Breakpoint 1 at 0x9afba75: file gestalt_test_driver48.c, line 24535.
(gdb) run
Starting program: /home/colin/gestalt/test/gestalt_test_driver --case=3Dacc=
essor20_018_01
[Thread debugging using libthread_db enabled]
[New Thread -1209092400 (LWP 17574)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1209092400 (LWP 17574)]
GC_clear_fl_links (flp=3D0xb84ee50) at reclaim.c:469
469            *flp =3D 0;
(gdb)=20
(gdb) backtrace
#0  GC_clear_fl_links (flp=3D0xb84ee50) at reclaim.c:469
#1  0x09b02382 in GC_start_reclaim (report_if_found=3D0) at reclaim.c:504
#2  0x09b05c47 in GC_finish_collection () at alloc.c:680
#3  0x09b09415 in GC_alloc_large (lb=3D3016, k=3D1, flags=3D0) at malloc.c:=
53
#4  0x09b09719 in GC_generic_malloc (lb=3D3015, k=3D1) at malloc.c:171
#5  0x09b098ba in GC_core_malloc (lb=3D3015) at malloc.c:286
#6  0x0804ace6 in GE_ms (
    s=3D0x9b50518 "%G=EF=BF=BD%@\204\215%G=EF=BF=BD=EF=BF=BD%@\210%G=EF=BF=
=BD=EF=BF=BD%@\210%G=EF=BF=BD=EF=BF=BD%@\210%G=EF=BF=BD=EF=BF=BD%@\210%G=EF=
=BF=BD=EF=BF=BD%@\210%G=EF=BF=BD=EF=BF=BD%@\210%G=EF=BF=BD=EF=BF=BD%@\210%G=
=EF=BF=BD=EF=BF=BD%@\210%G=EF=BF=BD=EF=BF=BD%@\210%G=EF=BF=BD=EF=BF=BD%@\21=
0%G=EF=BF=BD=EF=BF=BD%@\210%G=EF=BF=BD=EF=BF=BD%@\210%G=EF=BF=BD=EF=BF=BD%@=
\210%G=EF=BF=BD=EF=BF=BD%@\210%G=EF=BF=BD=EF=BF=BD%@\210%G=EF=BF=BD=EF=BF=
=BD%@\210%G=EF=BF=BD=EF=BF=BD%@\210%G=EF=BF=BD=EF=BF=BD%@\210%G=EF=BF=BD=EF=
=BF=BD%@\210%G=EF=BF=BD=EF=BF=BD%@\210%G=EF=BF=BD=EF=BF=BD%@\210%G=EF=BF=BD=
=EF=BF=BD%@\210%G=EF=BF=BD=EF=BF=BD%@\210%G=EF=BF=BD=EF=BF=BD%@\210%G=EF=BF=
=BD=EF=BF=BD%@\210%G=EF=BF=BD=EF=BF=BD%@\210%G=EF=BF=BD=EF=BF=BD%@\210%G=EF=
=BF=BD%@\204\215$(CBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBeBe%G=
=EF=BF=BD%@(B\204\215%G=EF=BF=BD=EF=BF=BD%@\200%G=EF=BF=BD=EF=BF=BD%@\200%G=
=EF=BF=BD=EF=BF=BD%@\200%G=EF=BF=BD=EF=BF=BD%@\200%G=EF=BF=BD=EF=BF=BD%@\20=
0%G=EF=BF=BD=EF=BF=BD%@\200%G=EF=BF=BD=EF=BF=BD%@\200%G=EF=BF=BD=EF=BF=BD%@=
\200%G=EF=BF=BD=EF=BF=BD%@\200%G=EF=BF=BD=EF=BF=BD%@"..., c=3D3003) at gest=
alt_test_driver1.c:1882
#7  0x09afa725 in GE_const_init () at gestalt_test_driver48.c:21933
#8  0x09afba25 in main (argc=3DCannot access memory at address 0x0
) at gestalt_test_driver48.c:24448
(gdb)=20

Where next?
--=20
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Colin P. A. <co...@co...>]

>>>>> "Eric" == Eric Bezault <er...@go...> writes:

    Eric> Colin Paul Adams wrote:
    Eric> One other thing that I would be interested in, even if it
    Eric> does not crash at the same location each time, is to know at
    Eric> which stage in the execution trace the message "Unhandled
    Eric> exception" is printed.  Could you try to put a break point
    Eric> in the C code at the beginning of the C function 'GE_raise'
    Eric> and see what the execution trace looks like?
    >> 
    >> How do I set a break point?

    Eric> I don't know. I guess it depends on the C debugger that is
    Eric> available under Linux. Under Windows I do that from Visual
    Eric> Studio.

OK - I'm using gdb.

I need to know which file to find GC_RAISE in. Is it part of gec or boehm?
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Colin P. A. <co...@co...>]

>>>>> "Eric" == Eric Bezault <er...@go...> writes:

    Eric> Can you try to compile the Boehm GC with the option
    Eric> -DLARGE_CONFIG?

No difference.
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Eric B. <er...@go...>]

Colin Paul Adams wrote:
>     Eric> One other thing that I would be interested in, even if it
>     Eric> does not crash at the same location each time, is to know at
>     Eric> which stage in the execution trace the message "Unhandled
>     Eric> exception" is printed.  Could you try to put a break point
>     Eric> in the C code at the beginning of the C function 'GE_raise'
>     Eric> and see what the execution trace looks like?
> 
> How do I set a break point?

I don't know. I guess it depends on the C debugger that
is available under Linux. Under Windows I do that from
Visual Studio.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Colin P. A. <co...@co...>]

>>>>> "Eric" == Eric Bezault <er...@go...> writes:

    Eric> Colin Paul Adams wrote:
    >>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
    >> 
    Eric> I have no idea how to debug what is going on in the Boehm
    Eric> GC.  Since you are using Linux, you can perhaps try valgrind
    Eric> (first with no GC and then with GC) to see if there is any
    Eric> memory corruption in the C code generated by gec (or less
    Eric> likely, in the Boehm GC).
    >> 
    >> There don't appear to be any problems without the garbage
    >> collector (of course, there are a lot of memory leaks).

    >> There are problems detected with the gc enabled. Here is the
    >> valgrind output:

    Eric> Do you get the same problems under Windows?

I've never tried to run the test suite under Windows, as it uses some
extra tools such as xmllint.

    Eric> Can you try to compile the Boehm GC with the option
    Eric> -DLARGE_CONFIG?

I will try that.

    Eric> One other thing that I would be interested in, even if it
    Eric> does not crash at the same location each time, is to know at
    Eric> which stage in the execution trace the message "Unhandled
    Eric> exception" is printed.  Could you try to put a break point
    Eric> in the C code at the beginning of the C function 'GE_raise'
    Eric> and see what the execution trace looks like?

How do I set a break point?
-- 
Colin Adams
Preston Lancashire

Re: [gobo-eiffel-develop] Unhandled exception from gec-compiled tests

[Eric B. <er...@go...>]

Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> 
>     Eric> I have no idea how to debug what is going on in the Boehm
>     Eric> GC.  Since you are using Linux, you can perhaps try valgrind
>     Eric> (first with no GC and then with GC) to see if there is any
>     Eric> memory corruption in the C code generated by gec (or less
>     Eric> likely, in the Boehm GC).
> 
> There don't appear to be any problems without the garbage collector
> (of course, there are a lot of memory leaks).

> There are problems detected with the gc enabled. Here is the valgrind
> output:

Do you get the same problems under Windows?

Can you try to compile the Boehm GC with the option -DLARGE_CONFIG?

One other thing that I would be interested in, even if it does not
crash at the same location each time, is to know at which stage
in the execution trace the message "Unhandled exception" is printed.
Could you try to put a break point in the C code at the beginning of
the C function 'GE_raise' and see what the execution trace looks like?

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com