Following are the first couple of lines that are generated by the metakit dump utility - they show the structure of the view that I am using.� The view structure is auto-generated dynamically from CORBA type-codes (I am using metakit to cache data that has�it's structure defined in CORBA IDL).� Hence I am using sub-views to store data that is contained within nested sequences defined within CORBA data structures.
I took that definition and created a small Tcl script to add rows, also to the subviews. The only thing I had to do is replace dots in names with underscores ("a_b" i.s.o. "a.b"), but that is probably a Tcl issue (I don't think dots in names are a problem in C++ or Python).
Added a few rows, also to subviews, and committed changes. All seems ok here.
The number of properties, sizes of names, number of rows, etc - none of these are larger than what some of the regression tests do.
#3� 0x4150e05d in __assert_fail () from /lib/libc.so.6
#4� 0x417d66a9 in c4_Column::Validate (this=0xbfe7a6f8) at ../src/univ.inl:44
#5� 0x417d6755 in c4_Column::~c4_Column (this=0xbfe7a6f8, __in_chrg=2) at ../unix/../src/column.cpp:86
This looks suspicious. You have checking enabled, and on cleanup of a column inside MK, it detects corruption.
The fact that problems happen during commit says little, unfortunately. Most of MK's work happens at that stage.
If a stray pointer write corrupts memory, then commit is the most likely place where the failure will happen.
You may want to use one of the memory checking tools to check against memory corruption (which could be anywhere in the program). I think "valgrind" can do this, on Linux. I'm not too familar with this sort of stuff, though.
The conclusion so far is that I don't see any limits which could have been exceeded. I don't see any other way out than to reduce and simplify until more clues can be found.
-jcw
_____________________________________________ Metakit mailing list - [EMAIL PROTECTED] http://www.equi4.com/mailman/listinfo/metakit
