Menu
▾
▴
gobo-eiffel-develop
|
From: Colin P. A. <co...@co...> - 2007-12-24 10:53:23
|
>>>>> "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
|
|
From: Colin P. A. <co...@co...> - 2007-12-24 11:31:58
|
>>>>> "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
|
|
From: Colin P. A. <co...@co...> - 2007-12-24 12:01:39
|
>>>>> "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
|
|
From: Colin P. A. <co...@co...> - 2007-12-24 12:35:28
|
>>>>> "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
|
|
From: Colin A. <col...@go...> - 2007-12-24 12:45:49
|
> 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. |
|
From: Eric B. <er...@go...> - 2007-12-24 14:02:05
|
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 |
|
From: Colin P. A. <co...@co...> - 2007-12-24 15:35:33
|
>>>>> "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
|
|
From: Colin A. <col...@go...> - 2007-12-26 10:02:12
|
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. |
|
From: Colin P. A. <co...@co...> - 2007-12-24 12:49:11
|
>>>>> "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
|
|
From: Eric B. <er...@go...> - 2007-12-24 15:50:13
|
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 |
|
From: Colin A. <col...@go...> - 2007-12-26 11:23:19
|
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 () |
|
From: Colin P. A. <co...@co...> - 2007-12-24 16:09:08
|
>>>>> "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
|
|
From: Colin P. A. <co...@co...> - 2007-12-24 16:27:08
|
>>>>> "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
|
|
From: Colin P. A. <co...@co...> - 2007-12-24 16:37:49
|
>>>>> "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
|
|
From: Eric B. <er...@go...> - 2007-12-24 16:52:55
|
Colin Paul Adams wrote: > I'll run the gobo test cases, and if they all pass, I'll check in my changes. Before doing that, what about getting a fresh copy from SVN and try your test case to see if it crashes or not? -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Eric B. <er...@go...> - 2007-12-24 19:14:08
|
Colin Paul Adams wrote: >>>>>> "Eric" == Eric Bezault <er...@go...> writes: > 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. It's probably too late for you, but it's now implemented in gec. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Eric B. <er...@go...> - 2007-12-26 12:47:49
|
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. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Colin P. A. <co...@co...> - 2007-12-26 14:03:30
|
>>>>> "Eric" == Eric Bezault <er...@go...> writes:
Eric> OK, but during the sort there is no guarantee that all items
Eric> in the list will be compared with all other items. So in
Eric> theory I guess it is possible to sort a list containing two
Eric> non comparable items without comparing them explicitly, and
Eric> hence without raising the exception.
An interesting point. I'm not sure.
The definition of the error code is:
"It is a non-recoverable dynamic error if, for any sort key component,
the set of sort key values evaluated for all the items in the initial
sequence, after any type conversion requested, contains a pair of
ordinary values for which the result of the XPath lt operator is an
error."
I'm not sure if I can follow the English involved. But I THINK it
means that whether or not a comparison is actually performed on the
pair involved, the error must still be raised.
In which case:
Eric> Anyway, if you want to report an XPath error, then I guess
Eric> that the proper way to do it is to write a routine that
Eric> takes the list as argument and returns true or false
Eric> depending on whether the list contains non comparable items
Eric> or not. If yes, then report the error, if not, the call `sort'.
the above approach is actually necessary (although more expensive) if
non-comparability is not transitive. I must dig into this.
Eric> In any case I really think that you need to use
Eric> KL_PART_COMPARATOR and not KL_COMPARATOR in order to avoid
Eric> having to raise an exception in the implementation, because
Eric> the contracts in class KL_COMPARATOR are not applicable in
Eric> your case.
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).
--
Colin Adams
Preston Lancashire
|
|
From: Colin P. A. <co...@co...> - 2007-12-26 14:32:04
|
>>>>> "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.
--
Colin Adams
Preston Lancashire
|
|
From: Colin P. A. <co...@co...> - 2007-12-26 14:51:48
|
>>>>> "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.
--
Colin Adams
Preston Lancashire
|
|
From: Colin P. A. <co...@co...> - 2007-12-26 15:09:14
|
>>>>> "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.
--
Colin Adams
Preston Lancashire
|
|
From: Berend de B. <be...@po...> - 2007-12-24 20:48:07
Attachments:
smime.p7s
|
>>>>> "Colin" =3D=3D Colin Paul Adams <co...@co...> writes:
>>>>> "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.
Colin> I guess eposix might be returning either of those.
eposix uses the former, not the later.
=2D-=20
Cheers,
Berend de Boer
|
|
From: Eric B. <er...@go...> - 2007-12-25 15:25:44
|
Colin Paul Adams wrote: > Anyway, reviewing my outstanding bugs on sourceforge, I wondered if > 1847164 was now fixed. > Not exactly. I get: > > 'eeocode' in 'eif_except.h' not implemented > 'stack_trace_string' in 'eif_except.h' not implemented > Call on Void target! > Unhandled exception > > I assume this is not "no more memory", but I'm going to recompile > anyway, to see what happens. If "no more memory", the message "No more memory" would be printed. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Eric B. <er...@go...> - 2007-12-25 22:33:56
|
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.
--
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com
|
|
From: Colin A. <col...@go...> - 2007-12-25 23:19:37
|
On 25/12/2007, Eric Bezault <er...@go...> wrote: > 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 don't know. I don't use them in my own classes. I tried checking with Eiffel Studio, and it reports no callers other than deep_clone, and deep_copy, and in turn reports no callers for those. But experience tells me that it doesn't always report all calls. But I checked that there are no other implementations except those in ANY. > 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. Well Berend can say whether or not they are used within eposix. I don't have any user-defined expanded classes in my own code that I remember (I don't think I have ever created an expanded class). Anyway, I will update my repository tomorrow, and see if it makes any difference. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X