Open mw66 opened 7 months ago
I cannot reproduce this issue.
During what Degree does gec
crash?
It's not the gec
compiler crash, it's the generated binary gedoc
run on /Eiffel_23.09/examples/docking/simple
project crash.
OK, so the proper way to reproduce the bug is to run:
gec --gc=no --capability=concurrency=none system.ecf
in $GOBO/tool/gedoc/src
and then run:
gedoc --format=field_rename docking_simple.ecf
in $ISE_EIFFEL/examples/docking/simple
.
I did not get a crash, but the application is hanging. This is due to a precondition violation. The problem is on this line. You try to insert more items in the hash table than the size it has been created for. So you need to call force
instead of put
so that the hash table will automatically resize itself.
Oh? I will fix my code.
But there are 2 things I see:
1) why didn't it report size violation message to the programmer? (program hang / crash is bad, because the programmer is clueless)
2) why it only happen with DS_HASH_TABLE, but not HASH_TABLE? these two classes are not interchangeable? I'd say that's bad design.
Oh? I will fix my code.
But there are 2 things I see:
1. why didn't it report size violation message to the programmer? (program hang / crash is bad, because the programmer is clueless)
In finalized mode, you don't get the assertion violations. gec
is designed to work in finalized mode (so far). For ISE Eiffel, you have to make sure that assertion monitoring are turned on in the ECF file. I would think that they are turn on by default in workbench mode, but I'm not sure.
2. why it only happen with DS_HASH_TABLE, but not HASH_TABLE? these two classes are not interchangeable? I'd say that's bad design.
There is no claim that they should be interchangeable. Class DS_HASH_TABLE
fixes some problems in HASH_TABLE
, which makes it difficult to not break some interoperability.
In this branch:
https://github.com/joortcom/gobo/tree/detect_diamond
in file
/gobo/tool/gedoc/src/gedoc_field_rename_format.e
if we change
HASH_TABLE
toDS_HASH_TABLE
, thegec
build program (viamake gobo
) will segfault.While ISE build program runs fine (via
make ise
).