[interfacekit] Re: Broken BMessage

On Wed, 18 Aug 2004, Erik Jaesler wrote:

is it possible that the current BMessage implementation is quite broken, or do I miss some important prerequisite?

It is quite possible, yes. Although the various Add/Find/Get functions are fairly well covered by unit tests, several APIs are not and sending is not.

Come to think of it, it might be that the Add/Find*() methods are perfectly bug-free and that only Flatten/Unflatten() screws up the internal data structure.

I'm in the process of cleaning up the Storage Kit code to run nicely on our kernel and am experiencing the annoying situation that none of the Storage Kit unit test that require communication with the registrar runs through; all crash in some BMessage code (mostly in some evil template code called by FindData(), but also in Unflatten()).

I have tested Flatten() and Unflatten() to some extent, although there are not any unit tests for it. Would you mind posting your code or pointing out where it is in CVS? I've been pretty well buried by real life for quite some time, but I will make an earnest attempt to track down the problem this week so that you're not held up any longer than possible.

The code is in the repository. It's the unit tests for BAppFileInfo, BNodeInfo, BMimeType -- each test crashs at some point (all require a running obos_registrar). I haven't checked the App Kit tests that should also be concerned (BMessenger, BApplication), but as Jack says, he experienced crashes in the BApplication tests, too.

I'm not sure to what degree the Storage Kit unit tests run with the libopenbeos built from the sources currently in CVS, though. My local copy is heavily modified, but I can't check it in yet, because it would break the libroot built. If the tests don't run to the point where the BMessage related crashes occur, I can try and analyze the exact situation under which the crashes occur and add a respective BMessage unit test.

BTW, my template code is not *evil*, merely Very Obnoxious -- it's a matter of intent. ;)

I didn't mean `evil' in the negative sense. ;-) They just defy quick analysis by an uninitiated, as everything is delegated to policies. The simple debugger is not happy either; it doesn't even manage to print the full symbol name of the crashing function.

In retrospect, the BMessage internals were not the best place to go hog wild experimenting after I finished reading "Modern C++ Design". =P I have recognized for a long time that a rewrite is in order. =\

I was hoping to maybe even get the registrar running on our kernel, but without working messaging that looks rather hopeless. :-(

I apologize for leaving BMessage lying there half-baked. I very much wish my time situation was more allowing of Haiku work. =( 

Such is (real) life. :-/

CU, Ingo

Other related posts: