gobo-eiffel-develop

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

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

On 25/12/2007, Eric Bezault <er...@go...> wrote:
> Colin Paul Adams wrote:
> > Maybe, maybe not. I may try the original problem (by removing the
> > parallel collecting option) to see if that catches it.
> > Then we might as well report a bug in boehm.
>
> I found (and fixed) a bug in `deep_twin':
>
>     * Fixed bug (read/write to non-allocated memory) in implementation of
>       `deep_twin' when traversing objects of type SPECIAL.
>
> Do you know if `deep_twin' is used in your program? It might explain
> the weird behavior that you get if the memory gets corrupted in such
> a way.
>
> I also improved things when declaring user-defined expanded types,
> in particular when creating SPECIAL objects of expanded). Feature
> `default_create' is still not called on initialization, and `copy'
> is still not called on reattachment. If neither of these are redefined
> in your user-defined expanded types, then it should now be safe to
> use them.

It doesn't fix the problems where I get:

In test-case errorcode1030: Finishing early, having processed test case
'eeocode' in 'eif_except.h' not implemented
'stack_trace_string' in 'eif_except.h' not implemented
Call on Void target!
Unhandled exception

How much effort is involved to implement that?

Nor does it affect the original problem (revealed by turning off
parallel marking in boehm gc).

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

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

Colin Adams wrote:
> It doesn't fix the problems where I get:
> 
> In test-case errorcode1030: Finishing early, having processed test case
> 'eeocode' in 'eif_except.h' not implemented
> 'stack_trace_string' in 'eif_except.h' not implemented
> Call on Void target!
> Unhandled exception
> 
> How much effort is involved to implement that?

The thing is that if `eeocode' and `stack_trace_string' are called,
it's because an exception has been raised in the first place. So
it might be interesting to know why an exception has been raise,
and when. So I suggest again that you put breakpoints in the generated
C code at the beginning of 'GE_raise', and also on function 'eeocode'.

It might be that eposix is relying too much on exceptions to program
expectable error cases! ;-)

The effort to implement it is not worth it. We are in the process to
move to exceptions implemented as objects.

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

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

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

On 26/12/2007, Eric Bezault <er...@go...> wrote:

> > How much effort is involved to implement that?
>
> The thing is that if `eeocode' and `stack_trace_string' are called,
> it's because an exception has been raised in the first place. So
> it might be interesting to know why an exception has been raise,
> and when. So I suggest again that you put breakpoints in the generated
> C code at the beginning of 'GE_raise', and also on function 'eeocode'.

I tried that.
In this case gdb does not break, but says "Program exited normally.".
However I do not get the correct output.
Maybe I can try stepping through the code to see what is happening.
Does gec provide an eiffel-to-c function name mapping?

> It might be that eposix is relying too much on exceptions to program
> expectable error cases! ;-)

That may be the case, but this test case is not using any of the
network stuff, so eposix code is not actually being exercised by the
test case.

> The effort to implement it is not worth it. We are in the process to
> move to exceptions implemented as objects.

OK. That makes sense.

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

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

Colin Adams wrote:
> In this case gdb does not break, but says "Program exited normally.".
> However I do not get the correct output.
> Maybe I can try stepping through the code to see what is happening.
> Does gec provide an eiffel-to-c function name mapping?

No, mapping has to be done manually by looking at the generated .h file.

Note that the "trace" option works, but the program runs much slower
and in my experience the output is harder to make sense of than the
C execution trace. This is because "trace" does not provide an
execution trace, but prints to the output a message each time the
execution enters or exits a routine. I started to implement an
Eiffel execution trace mechanism, but I stopped when I realized that
for what I was doing it was faster to use the C execution trace
and then translate the function names manually than to implement
the Eiffel execution trace mechanism.

-- 
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:
> On 26/12/2007, Colin Adams <col...@go...> wrote:
> 
>> In test-case errorcode1030: Finishing early, having processed test case
>> 'eeocode' in 'eif_except.h' not implemented
>> 'stack_trace_string' in 'eif_except.h' not implemented
>> Call on Void target!
>> Unhandled exception
> 
> This problem also occurs on Windows.

Can you tell me how to reproduce it?

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

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

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

On 26/12/2007, Eric Bezault <er...@go...> wrote:
> Colin Adams wrote:
> > On 26/12/2007, Colin Adams <col...@go...> wrote:
> >
> >> In test-case errorcode1030: Finishing early, having processed test case
> >> 'eeocode' in 'eif_except.h' not implemented
> >> 'stack_trace_string' in 'eif_except.h' not implemented
> >> Call on Void target!
> >> Unhandled exception
> >
> > This problem also occurs on Windows.
>
> Can you tell me how to reproduce it?

Compile gexslt with boehm.

Then the following command line reproduces it:

gexslt --template=main errorcode1030.xsl

where errorcode1030.xsl look like this:

<?xml version="1.0"?>

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="2.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:my="http://my.com/">

<?error XTDE1030?>


  <xsl:template name="main">
    <out>
      <xsl:for-each select="1 to 5, 'fred'">
        <xsl:sort select="."/>
        <xsl:value-of select="."/>
      </xsl:for-each>
    </out>
  </xsl:template>




</xsl:stylesheet>

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

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

OK - mystery solved.

The function concerned is:

XM_XPATH_ATOMIC_SORT_COMPARER.raise_non_comparable_exception

This is the sole exception in the XPath library, and it does not leak
out of any API.
But it's a problem when compiled with gec at the moment.

I couldn't find a design to report the error except by using an
internal exception.

On 26/12/2007, Colin Adams <col...@go...> wrote:
> On 26/12/2007, Colin Adams <col...@go...> wrote:
> > On 26/12/2007, Eric Bezault <er...@go...> wrote:
> >
> > > > How much effort is involved to implement that?
> > >
> > > The thing is that if `eeocode' and `stack_trace_string' are called,
> > > it's because an exception has been raised in the first place. So
> > > it might be interesting to know why an exception has been raise,
> > > and when. So I suggest again that you put breakpoints in the generated
> > > C code at the beginning of 'GE_raise', and also on function 'eeocode'.
> >
> > I tried that.
> > In this case gdb does not break, but says "Program exited normally.".
>
> I forgot that I had commented out the test case from the catalog.
> When I restored it, I now get a break at GE_raise. Here is the stack trace:
>
> (gdb) backtrace
> #0  0x09b02216 in GE_raise ()
> #1  0x09b023af in eraise ()
> #2  0x084b07b9 in T24f12 ()
> #3  0x084b078b in T24f11 ()
> #4  0x093de773 in T1809f12 ()
> #5  0x093de701 in T1809f5 ()
> #6  0x082af3e2 in T1820x31356T0T0 ()
> #7  0x08965ec5 in T2167f35 ()
> #8  0x08964ece in T2262f5 ()
> #9  0x089647be in T2262f4 ()
> #10 0x0896470d in T2262f3 ()
> #11 0x0896773c in T2167f41 ()
> #12 0x08967582 in T2167f38 ()
> #13 0x0895878b in T2167f37 ()
> #14 0x082eee23 in T422x20234 ()
> #15 0x0847934e in T2020f301 ()
> #16 0x08b45262 in T2020f302 ()
> #17 0x082d5ddb in T405x18742T0 ()
> #18 0x084a3e9e in T1978f316 ()
> #19 0x0831b4cb in T2128x21386T0T0 ()
> #20 0x0845cc6d in T393f13 ()
> #21 0x0922cfb6 in T317f84 ()
> ---Type <return> to continue, or q <return> to quit---
> #22 0x093769a8 in T317f77 ()
> #23 0x093757d6 in T276f81 ()
> #24 0x0937529f in T276f69 ()
> #25 0x0936c75b in T27f163 ()
> #26 0x082b10f9 in T42x2331T0T0T0 ()
> #27 0x0936c47c in T56f33p1 ()
> #28 0x0936be80 in T56f33 ()
> #29 0x082b1125 in T42x2331T0T0T0 ()
> #30 0x0936bd75 in T57f12p1 ()
> #31 0x0936bd0c in T57f12 ()
> #32 0x082b1151 in T42x2331T0T0T0 ()
> #33 0x0838dcfa in T62f250 ()
> #34 0x0832f285 in T62f229 ()
> #35 0x08321358 in T62f220 ()
> #36 0x08320be4 in T62f216 ()
> #37 0x0831d52d in T62f213 ()
> #38 0x0831d46c in T62f207 ()
> #39 0x0831c8ec in T27f152 ()
> #40 0x0831c469 in T21c13 ()
> #41 0x09b021d2 in main ()
>

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

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

On 26/12/2007, Eric Bezault <er...@go...> wrote:
> Colin Adams wrote:
> > OK - mystery solved.
> >
> > The function concerned is:
> >
> > XM_XPATH_ATOMIC_SORT_COMPARER.raise_non_comparable_exception
> >
> > This is the sole exception in the XPath library, and it does not leak
> > out of any API.
> > But it's a problem when compiled with gec at the moment.
> >
> > I couldn't find a design to report the error except by using an
> > internal exception.
>
> I guess you need to inherit from KL_PART_COMPARATOR instead
> of KL_COMPARATOR.

I don't see how that helps.

If two atomic values are comparable, I need to call less_than.

But if they are not comparable, then I need to raise an XPath error.

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

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

Colin Adams wrote:
> On 26/12/2007, Eric Bezault <er...@go...> wrote:
>> Colin Adams wrote:
>>> OK - mystery solved.
>>>
>>> The function concerned is:
>>>
>>> XM_XPATH_ATOMIC_SORT_COMPARER.raise_non_comparable_exception
>>>
>>> This is the sole exception in the XPath library, and it does not leak
>>> out of any API.
>>> But it's a problem when compiled with gec at the moment.
>>>
>>> I couldn't find a design to report the error except by using an
>>> internal exception.
>> I guess you need to inherit from KL_PART_COMPARATOR instead
>> of KL_COMPARATOR.
> 
> I don't see how that helps.
> 
> If two atomic values are comparable, I need to call less_than.
> 
> But if they are not comparable, then I need to raise an XPath error.

OK, but during the sort there is no guarantee that all items
in the list will be compared with all other items. So in
theory I guess it is possible to sort a list containing two
non comparable items without comparing them explicitly, and
hence without raising the exception.

Anyway, if you want to report an XPath error, then I guess that
the proper way to do it is to write a routine that takes the
list as argument and returns true or false depending on whether
the list contains non comparable items or not. If yes, then
report the error, if not, the call `sort'. In any case I really
think that you need to use KL_PART_COMPARATOR and not KL_COMPARATOR
in order to avoid having to raise an exception in the implementation,
because the contracts in class KL_COMPARATOR are not applicable in
your case.

-- 
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:
> OK - mystery solved.
> 
> The function concerned is:
> 
> XM_XPATH_ATOMIC_SORT_COMPARER.raise_non_comparable_exception

I don't understand this implementation in class
XM_XPATH_ATOMIC_COMPARER:

~~~~~~~~~~~~~~~~~~~~~~~~
	are_comparable (an_atomic_value, another_atomic_value: 
XM_XPATH_ATOMIC_VALUE): BOOLEAN is
			-- Are `an_atomic_value' and `another_atomic_value' comparable?
		require
			first_value_not_void: an_atomic_value /= Void
			second_value_not: another_atomic_value /= Void
		do
			if an_atomic_value.is_untyped_atomic then
				Result := an_atomic_value.as_untyped_atomic.is_comparable 
(another_atomic_value)
			else
				if an_atomic_value.is_numeric_value then
					Result := an_atomic_value.as_numeric_value.is_comparable 
(another_atomic_value)
				else
					if an_atomic_value.is_string_value then
						Result := an_atomic_value.as_string_value.is_comparable 
(another_atomic_value)
					else
						Result := an_atomic_value.is_comparable (another_atomic_value)
					end
				end
			end
		end
~~~~~~~~~~~~~~~~~~~~~~~~

How is it different from:

~~~~~~~~~~~~~~~~~~~~~~~~
	are_comparable (an_atomic_value, another_atomic_value: 
XM_XPATH_ATOMIC_VALUE): BOOLEAN is
			-- Are `an_atomic_value' and `another_atomic_value' comparable?
		require
			first_value_not_void: an_atomic_value /= Void
			second_value_not: another_atomic_value /= Void
		do
			Result := an_atomic_value.is_comparable (another_atomic_value)
		end
~~~~~~~~~~~~~~~~~~~~~~~~

-- 
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 Adams wrote:
    >> OK - mystery solved.
    >> 
    >> The function concerned is:
    >> 
    >> XM_XPATH_ATOMIC_SORT_COMPARER.raise_non_comparable_exception

    Eric> I don't understand this implementation in class
    Eric> XM_XPATH_ATOMIC_COMPARER:

    Eric> ~~~~~~~~~~~~~~~~~~~~~~~~ are_comparable (an_atomic_value,
    Eric> another_atomic_value: XM_XPATH_ATOMIC_VALUE): BOOLEAN is --
    Eric> Are `an_atomic_value' and `another_atomic_value' comparable?
    Eric> require first_value_not_void: an_atomic_value /= Void
    Eric> second_value_not: another_atomic_value /= Void do if
    Eric> an_atomic_value.is_untyped_atomic then Result :=
    Eric> an_atomic_value.as_untyped_atomic.is_comparable
    Eric> (another_atomic_value) else if
    Eric> an_atomic_value.is_numeric_value then Result :=
    Eric> an_atomic_value.as_numeric_value.is_comparable
    Eric> (another_atomic_value) else if
    Eric> an_atomic_value.is_string_value then Result :=
    Eric> an_atomic_value.as_string_value.is_comparable
    Eric> (another_atomic_value) else Result :=
    Eric> an_atomic_value.is_comparable (another_atomic_value) end end
    Eric> end end ~~~~~~~~~~~~~~~~~~~~~~~~

    Eric> How is it different from:

    Eric> ~~~~~~~~~~~~~~~~~~~~~~~~ are_comparable (an_atomic_value,
    Eric> another_atomic_value: XM_XPATH_ATOMIC_VALUE): BOOLEAN is --
    Eric> Are `an_atomic_value' and `another_atomic_value' comparable?
    Eric> require first_value_not_void: an_atomic_value /= Void
    Eric> second_value_not: another_atomic_value /= Void do Result :=
    Eric> an_atomic_value.is_comparable (another_atomic_value) end
    Eric> ~~~~~~~~~~~~~~~~~~~~~~~~

I can't tell either. So I've simplifed it.

I think this may have come from splitting out
XM_XPATH_ATOMIC_SORT_COMPARER as a separate class, but also I note
from the early history that I initially hadn't implemented all types,
and was testing for this and raising an exception for the unimplented
cases.
Then I guess I must have gradually added other types in, and failed to
notice that at the end there was no longer a need for the tests.
-- 
Colin Adams
Preston Lancashire

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

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

Colin Paul Adams wrote:
> I still don't see why inheriting from KL_PART_COMPARATOR would make a
> difference.
> Anyway, XM_XPATH_ATOMIC_COMPARER needs to inherit from KL_COMPARATOR
> as less_equal is used elsewhere (XM_XPATH_MINIMAX_ROUTINES).

KL_PART_COMPARATOR also provides `less_than'. But there is no
such assumption as: not (a < b) and not (b < a) implies a equal b.
So, when not comparable, instead of raising an exception you can
just return false. If your items are not all comparable, then
KL_COMPARATOR is not the right abstraction (you don't have a
total order relation).

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

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> KL_PART_COMPARATOR also provides `less_than'. But there is
>     Eric> no such assumption as: not (a < b) and not (b < a) implies a
>     Eric> equal b.  So, when not comparable, instead of raising an
>     Eric> exception you can just return false. If your items are not
>     Eric> all comparable, then KL_COMPARATOR is not the right
>     Eric> abstraction (you don't have a total order relation).
> 
> OK. I see your point.
> As I can't use KL_PART_COMPARATOR, I shall have to think afresh about
> the complete desigmn.

Why can't you use KL_PART_COMPARATOR?

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

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> Why can't you use KL_PART_COMPARATOR?
> 
> Because it doesn't include less_equal, which is used elsewhere, as I
> mentioned a few messages ago.

Why can't you add this routine in your class? Does it really need to
be inherited?

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

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> Why can't you use KL_PART_COMPARATOR?
>     >> 
>     >> Because it doesn't include less_equal, which is used elsewhere,
>     >> as I mentioned a few messages ago.
> 
>     Eric> Why can't you add this routine in your class? Does it really
>     Eric> need to be inherited?
> 
> Maybe not.
> As i said, I have to rethink the whole design.

In fact it would probably be better that you provide your
own implementation of `less_equal' (using `less_than' and
`is_equal' -- or a routine other than `is_equal' which is
not CAT-call error prone) rather than relying on the
version from KL_COMPARATOR (which assumes total order).

Another solution is that you write:

~~~~~~~~~~~~~~~
if local_comparer.less_than (atomic_value, second_atomic_value) then
    atomic_value := second_atomic_value
end
~~~~~~~~~~~~~~~

instead of:

~~~~~~~~~~~~~~~
if local_comparer.less_equal (second_atomic_value, atomic_value) then
    atomic_value := second_atomic_value
end
~~~~~~~~~~~~~~~

in XM_XPATH_MINIMAX_ROUTINES.establish_next_primitive_type.

-- 
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> Another solution is that you write:

    Eric> ~~~~~~~~~~~~~~~ if local_comparer.less_than (atomic_value,
    Eric> second_atomic_value) then atomic_value :=
    Eric> second_atomic_value end ~~~~~~~~~~~~~~~

    Eric> instead of:

    Eric> ~~~~~~~~~~~~~~~ if local_comparer.less_equal
    Eric> (second_atomic_value, atomic_value) then atomic_value :=
    Eric> second_atomic_value end ~~~~~~~~~~~~~~~

    Eric> in XM_XPATH_MINIMAX_ROUTINES.establish_next_primitive_type.

I adopted that approach (after adding the missing not).

I have left the exception in to avoid the unnecessary quadratic
behaviour (quick sort is supposed to be nlogn on average), as the
situation only occurs for a fatal error code, so it is not too big a
deal that I get a crash instead temporarily (anyone who objects can
compile with ISE).
-- 
Colin Adams
Preston Lancashire

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

[Berend de B. <be...@po...>]

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

    Eric> * use of user-defined expanded classes * call to external
    Eric> routines returning an object whose type is not a basic
    Eric> expanded type or STRING.
    >>=20
    Colin> I guess eposix might be returning either of those.
    >>=20
    >> eposix uses the former, not the later.

    Eric> OK, so I will try to implement user-defined expanded types
    Eric> before taking care of DbC ;-)

Perhaps eposix doesn't actually do what you actually meant. I use a lot
of:

  test is
    local
      mem: expanded memory
    do
    end

kind of constructions. Expand this or that class. The use is that I
don't have to create it and can access it features and don't "pollute"
the current class by inheriting from it.

eposix doesn't have a class that says expanded in the class definition,
so perhaps you can start on DbC :-)

I've learnt to do without after experiencing issues with it with
compilers years ago. Not sure if it was ISE or SmartEiffel or
VisualEiffel, one of those didn't handle or like them well.

=2D-=20
Cheers,

Berend de Boer

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

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

Berend de Boer wrote:
> Perhaps eposix doesn't actually do what you actually meant. I use a lot
> of:
> 
>   test is
>     local
>       mem: expanded memory
>     do
>     end
> 
> kind of constructions. Expand this or that class. The use is that I
> don't have to create it and can access it features and don't "pollute"
> the current class by inheriting from it.
> 
> eposix doesn't have a class that says expanded in the class definition,
> so perhaps you can start on DbC :-)

No, because it does not matter whether the expandedness is declared in
the class definition or in the type declaration. It's still expanded.

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