Menu
▾
▴
gobo-eiffel-develop
|
From: Eric B. <er...@go...> - 2008-03-01 14:17:00
|
Colin Paul Adams wrote: >>>>>> "Eric" == Eric Bezault <er...@go...> writes: > > Eric> Before doing that, I would suggest using the following two > Eric> files ge_gc.h and ge_gc.c, and comment out the body of the > Eric> `dispose' routine in the 3 classes that you mentioned and > Eric> call `do_nothing' in these 3 `dispose' routines instead. > Eric> (You have to call `do_nothing' otherwise the whole `dispose' > Eric> routine will be optimized out by gec.) > > I now get the segmentation fault again (no other messages). OK, I will have to change the C code generated by gec. I'll let you know when it's ready. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Eric B. <er...@go...> - 2008-03-01 18:16:28
|
Eric Bezault wrote: > Colin Paul Adams wrote: >>>>>>> "Eric" == Eric Bezault <er...@go...> writes: >> Eric> Before doing that, I would suggest using the following two >> Eric> files ge_gc.h and ge_gc.c, and comment out the body of the >> Eric> `dispose' routine in the 3 classes that you mentioned and >> Eric> call `do_nothing' in these 3 `dispose' routines instead. >> Eric> (You have to call `do_nothing' otherwise the whole `dispose' >> Eric> routine will be optimized out by gec.) >> >> I now get the segmentation fault again (no other messages). > > OK, I will have to change the C code generated by gec. > I'll let you know when it's ready. You can try to get the latest code from SVN, and then recompile gec. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Colin P. A. <co...@co...> - 2008-03-01 19:28:03
|
>>>>> "Eric" == Eric Bezault <er...@go...> writes:
>> OK, I will have to change the C code generated by gec. I'll
>> let you know when it's ready.
Eric> You can try to get the latest code from SVN, and then
Eric> recompile gec.
I still get a segmentation fault.
--
Colin Adams
Preston Lancashire
|
|
From: Eric B. <er...@go...> - 2008-03-01 19:47:54
|
Colin Paul Adams wrote: >>>>>> "Eric" == Eric Bezault <er...@go...> writes: > > >> OK, I will have to change the C code generated by gec. I'll > >> let you know when it's ready. > > Eric> You can try to get the latest code from SVN, and then > Eric> recompile gec. > > I still get a segmentation fault. And if you replace line 68 in ge_gc.h: #define GE_register_dispose(obj, disp) GC_REGISTER_FINALIZER((void*)(obj), (void (*) (void*, void*)) &GE_boehm_dispose, (void*)(disp), NULL, NULL) by: #define GE_register_dispose(obj, disp) GC_REGISTER_FINALIZER((void*)(obj), (void (*) (void*, void*)) &GE_boehm_dispose, NULL, NULL, NULL) -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Colin P. A. <co...@co...> - 2008-03-01 19:56:48
|
>>>>> "Eric" == Eric Bezault <er...@go...> writes:
Eric> Colin Paul Adams wrote:
>>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
>>
>> >> OK, I will have to change the C code generated by gec. I'll
>> >> let you know when it's ready.
>>
Eric> You can try to get the latest code from SVN, and then
Eric> recompile gec.
>>
>> I still get a segmentation fault.
Eric> And if you replace line 68 in ge_gc.h:
Eric> #define GE_register_dispose(obj, disp)
Eric> GC_REGISTER_FINALIZER((void*)(obj), (void (*) (void*,
Eric> void*)) &GE_boehm_dispose, (void*)(disp), NULL, NULL)
Eric> by:
Eric> #define GE_register_dispose(obj, disp)
Eric> GC_REGISTER_FINALIZER((void*)(obj), (void (*) (void*,
Eric> void*)) &GE_boehm_dispose, NULL, NULL, NULL)
Same.
--
Colin Adams
Preston Lancashire
|
|
From: Eric B. <er...@go...> - 2008-03-01 20:11:06
Attachments:
ge_gc.c
|
Colin Paul Adams wrote: >>>>>> "Eric" == Eric Bezault <er...@go...> writes: > > Eric> Colin Paul Adams wrote: > >>>>>>> "Eric" == Eric Bezault <er...@go...> writes: > >> > >> >> OK, I will have to change the C code generated by gec. I'll > >> >> let you know when it's ready. > >> > Eric> You can try to get the latest code from SVN, and then > Eric> recompile gec. > >> > >> I still get a segmentation fault. > > Eric> And if you replace line 68 in ge_gc.h: > > Eric> #define GE_register_dispose(obj, disp) > Eric> GC_REGISTER_FINALIZER((void*)(obj), (void (*) (void*, > Eric> void*)) &GE_boehm_dispose, (void*)(disp), NULL, NULL) > > Eric> by: > > Eric> #define GE_register_dispose(obj, disp) > Eric> GC_REGISTER_FINALIZER((void*)(obj), (void (*) (void*, > Eric> void*)) &GE_boehm_dispose, NULL, NULL, NULL) > > > Same. Damn it! At least I now know one thing: it is not because of mixing void* and function pointers. There is no such mixing anymore. So the problem is somewhere else. Can you compile with this new ge_gc.c file? It will display messages of the form: Current = 1C35800 Class ID = 342 Dispose = 6432C0 instead of calling the "real" Eiffel `dispose' feature. I want to see whether Current or Dispose may happen to be null. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Colin P. A. <co...@co...> - 2008-03-01 20:18:47
|
>>>>> "Eric" == Eric Bezault <er...@go...> writes:
Eric> Damn it! At least I now know one thing: it is not because of
Eric> mixing void* and function pointers. There is no such mixing
Eric> anymore.
Eric> So the problem is somewhere else. Can you compile with this
Eric> new ge_gc.c file?
Sure.
I take it that both this case and the last just involved re-compiling
gestalt? (the message prior to that, you said re-compile gec, but I
ran the bootstrap to make sure).
--
Colin Adams
Preston Lancashire
|
|
From: Eric B. <er...@go...> - 2008-03-01 20:20:38
|
Colin Paul Adams wrote: >>>>>> "Eric" == Eric Bezault <er...@go...> writes: > > Eric> Damn it! At least I now know one thing: it is not because of > Eric> mixing void* and function pointers. There is no such mixing > Eric> anymore. > > Eric> So the problem is somewhere else. Can you compile with this > Eric> new ge_gc.c file? > > Sure. > > I take it that both this case and the last just involved re-compiling > gestalt? Yes, modifications in ge_gc.h and ge_gc.c don't require a recompilation of gec. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Colin P. A. <co...@co...> - 2008-03-01 20:27:31
|
>>>>> "Eric" == Eric Bezault <er...@go...> writes:
Eric> Colin Paul Adams wrote:
>>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
>>
Eric> Damn it! At least I now know one thing: it is not because of
Eric> mixing void* and function pointers. There is no such mixing
Eric> anymore.
>>
Eric> So the problem is somewhere else. Can you compile with this
Eric> new ge_gc.c file?
It works, and prints:
Current = 1CDB9E0
Class ID = 350
Dispose = 7BE320
--
Colin Adams
Preston Lancashire
|
|
From: Eric B. <er...@go...> - 2008-03-01 20:29:44
|
Colin Paul Adams wrote: >>>>>> "Eric" == Eric Bezault <er...@go...> writes: > > Eric> Colin Paul Adams wrote: > >>>>>>> "Eric" == Eric Bezault <er...@go...> writes: > >> > Eric> Damn it! At least I now know one thing: it is not because of > Eric> mixing void* and function pointers. There is no such mixing > Eric> anymore. > >> > Eric> So the problem is somewhere else. Can you compile with this > Eric> new ge_gc.c file? > > It works, and prints: > > Current = 1CDB9E0 > Class ID = 350 > Dispose = 7BE320 And if you uncomment the line 24 in ge_gc.c it crashes, right? -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Colin P. A. <co...@co...> - 2008-03-01 20:35:47
|
>>>>> "Eric" == Eric Bezault <er...@go...> writes:
Eric> Colin Paul Adams wrote:
>>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
>>
Eric> Colin Paul Adams wrote:
> >>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
>> >> Eric> Damn it! At least I now know one thing: it is not
>> because of
Eric> mixing void* and function pointers. There is no such mixing
Eric> anymore.
>> >> Eric> So the problem is somewhere else. Can you compile with
>> this
Eric> new ge_gc.c file?
>>
>> It works, and prints:
>>
>> Current = 1CDB9E0 Class ID = 350 Dispose = 7BE320
Eric> And if you uncomment the line 24 in ge_gc.c it crashes,
Eric> right?
Correct - after printing the same information.
--
Colin Adams
Preston Lancashire
|
|
From: Eric B. <er...@go...> - 2008-03-01 20:44:25
|
Colin Paul Adams wrote:
>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
>
> Eric> Colin Paul Adams wrote:
> >>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> >>
> Eric> Colin Paul Adams wrote:
>>>>>>>>> "Eric" == Eric Bezault <er...@go...> writes:
> >> >> Eric> Damn it! At least I now know one thing: it is not
> >> because of
> Eric> mixing void* and function pointers. There is no such mixing
> Eric> anymore.
> >> >> Eric> So the problem is somewhere else. Can you compile with
> >> this
> Eric> new ge_gc.c file?
> >>
> >> It works, and prints:
> >>
> >> Current = 1CDB9E0 Class ID = 350 Dispose = 7BE320
>
> Eric> And if you uncomment the line 24 in ge_gc.c it crashes,
> Eric> right?
>
> Correct - after printing the same information.
We are making some progress. I'm now more or less convinced that the
problem is not in the way I invoke the Boehm's finalizer registration.
Now I want to know which Eiffel `dispose' routine get called.
Can you search for "T350" in file gestalt.h and tell me what is
the corresponding Eiffel class?
Also, in the last or next to last gestaltN.c file, there is the
declaration of GE_types[]. Go to the line which starts with "{0, 350"
and tell me what is the last entry of the corresponding record.
Then, do a global search on all the gestaltN.c files to find the
C function whose name was listed as last entry of the record
above. Can you send me the C code corresponding to this routine?
--
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com
|
|
From: Colin P. A. <co...@co...> - 2008-03-01 21:04:01
|
>>>>> "Eric" == Eric Bezault <er...@go...> writes:
Eric> Can you search for "T350" in file gestalt.h and tell me what
Eric> is the corresponding Eiffel class?
MANAGED_POINTER
Eric> Also, in the last or next to last gestaltN.c file, there is
Eric> the declaration of GE_types[]. Go to the line which starts
Eric> with "{0, 350" and tell me what is the last entry of the
Eric> corresponding record.
Not sure what you mean. the line reads:
{0, 350, EIF_FALSE, &T350f12}
So is T350f12 the answer you want?
Eric> Then, do a global search on all the gestaltN.c files to find
Eric> the C function whose name was listed as last entry of the
Eric> record above. Can you send me the C code corresponding to
Eric> this routine?
If so, then this is the code:
/* MANAGED_POINTER.dispose */
void T350f12(GE_call* ac, T0* C)
{
GE_call tc = {0,0,ac};
T1 t1;
T14 l1 = 0;
t1 = ((T1)(!(((T350*)(C))->a3)));
if (t1) {
T14f8(&tc, &(((T350*)(C))->a1));
}
((T350*)(C))->a1 = l1;
((T350*)(C))->a3 = EIF_FALSE;
}
--
Colin Adams
Preston Lancashire
|
|
From: Eric B. <er...@go...> - 2008-03-01 21:21:41
|
Colin Paul Adams wrote:
> /* MANAGED_POINTER.dispose */
> void T350f12(GE_call* ac, T0* C)
> {
> GE_call tc = {0,0,ac};
> T1 t1;
> T14 l1 = 0;
fprintf(stderr, "Line 1\n");
> t1 = ((T1)(!(((T350*)(C))->a3)));
fprintf(stderr, "Line 2\n");
> if (t1) {
fprintf(stderr, "Line 3\n");
fprintf(stderr, "Item = %lX\n", ((T350*)(C))->a1);
> T14f8(&tc, &(((T350*)(C))->a1));
fprintf(stderr, "Line 4\n");
> }
fprintf(stderr, "Line 5\n");
> ((T350*)(C))->a1 = l1;
fprintf(stderr, "Line 6\n");
> ((T350*)(C))->a3 = EIF_FALSE;
fprintf(stderr, "Line 7\n");
> }
Can you put some debug printing, as shown above, and
recompile the C code (by running gestalt.sh for example)?
I want to see where it crashes. My guess is that it's
in T14f8.
--
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com
|
|
From: Colin P. A. <co...@co...> - 2008-03-02 06:41:52
|
>>>>> "Eric" == Eric Bezault <er...@go...> writes:
Eric> The difference between when it works and when it does not
Eric> work is not the fact that you use ePosix or not, but the
Eric> fact that you compile with the option "exception_trace" or
Eric> not. If you remove the option "exception_trace" from your
Eric> Xace file, gestalt should work without crashing.
It does. Well done.
It's rather fortuitous that this came to light. Jann Roeder pointed
out to me that ISE-compiled programs run nearly twice as slow with
exception trace turned on. So I turned it off, but I must have failed
to commit the change, or turned it back on again.
--
Colin Adams
Preston Lancashire
|
|
From: Eric B. <er...@go...> - 2008-03-02 15:13:06
|
Colin Paul Adams wrote: >>>>>> "Eric" == Eric Bezault <er...@go...> writes: > > Eric> The difference between when it works and when it does not > Eric> work is not the fact that you use ePosix or not, but the > Eric> fact that you compile with the option "exception_trace" or > Eric> not. If you remove the option "exception_trace" from your > Eric> Xace file, gestalt should work without crashing. > > It does. Well done. It's now fixed in the new version of gec in SVN. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Eric B. <er...@go...> - 2008-03-01 21:32:47
|
Colin Paul Adams wrote: >>>>>> "Eric" == Eric Bezault <er...@go...> writes: > > Eric> Can you put some debug printing, as shown above, and > > Current = 1CDB9E0 > Class ID = 350 > Dispose = 7BE320 > > Line 1 > Segmentation fault YEEEEEEEESSSSSSSSSS! Got it! The difference between when it works and when it does not work is not the fact that you use ePosix or not, but the fact that you compile with the option "exception_trace" or not. If you remove the option "exception_trace" from your Xace file, gestalt should work without crashing. The signature of a function in exception trace mode is: void T350f12(GE_call* ac, T0* C) In non-trace mode it is: void T350f12(T0* C) Gec's mistake is to alway call the dispose routine with only one argument (the Current object being disposed), even in exception_trace mode. (FYI, exception_trace is only partially implement in gec, and does not work yet.) -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Eric B. <er...@go...> - 2008-03-01 21:58:58
|
Eric Bezault wrote: > Colin Paul Adams wrote: >>>>>>> "Eric" == Eric Bezault <er...@go...> writes: >> Eric> Can you put some debug printing, as shown above, and >> >> Current = 1CDB9E0 >> Class ID = 350 >> Dispose = 7BE320 >> >> Line 1 >> Segmentation fault > > YEEEEEEEESSSSSSSSSS! Got it! > > The difference between when it works and when it does not work > is not the fact that you use ePosix or not, but the fact that > you compile with the option "exception_trace" or not. If you remove > the option "exception_trace" from your Xace file, gestalt should > work without crashing. The signature of a function in exception > trace mode is: > > void T350f12(GE_call* ac, T0* C) > > In non-trace mode it is: > > void T350f12(T0* C) > > Gec's mistake is to alway call the dispose routine with only > one argument (the Current object being disposed), even in > exception_trace mode. I have to give up for tonight. I will fix gec tomorrow so that it takes into account the fact that the exception_trace option has been specified when calling the dispose feature. -- Eric Bezault mailto:er...@go... http://www.gobosoft.com |
|
From: Emmanuel S. [ES] <ma...@ei...> - 2008-03-02 06:46:26
|
> It's rather fortuitous that this came to light. Jann Roeder > pointed out to me that ISE-compiled programs run nearly twice > as slow with exception trace turned on. So I turned it off, Only when a lot of small functions are called where the cost of recording outweight the computation. For example, for the EiffelStudio compiler the slowdown is between 5 to 25% depending on the platform, strangely the platform as a lot to do with this figure as one would expect the same percentage on all the platforms since this is the same C code involved. Manu |
|
From: Colin P. A. <co...@co...> - 2008-03-02 06:50:34
|
>>>>> "Emmanuel" == Emmanuel Stapf [ES] <ma...@ei...> writes:
Emmanuel> Only when a lot of small functions are called where the
Emmanuel> cost of recording outweight the computation. For
Emmanuel> example, for the EiffelStudio compiler the slowdown is
Emmanuel> between 5 to 25% depending on the platform
To be fair to Jann, he only said it was a high overhead. It was my
measurements on Gestalt on Linux 64-bit that indicated roughly double
elapsed time.
--
Colin Adams
Preston Lancashire
|
×
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