[interfacekit] Re: Broken BMessage

On 2004-08-19 at 16:41:46 [+0200], Erik Jaesler wrote:
> Ingo Weinhold wrote:
> > On Wed, 18 Aug 2004, Erik Jaesler wrote:
> > 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 wouldn't be surprized.  As it is, Flatten() and Unflatten() are
> precisely where all my "nice" abstractions break down.  Strings and
> other variable-length "buffer"-style data are largely responsible for
> that and the resulting multitude of policy classes.  IIRC, there were
> two simple policy classes before I had to deal with that. =\
> 
> > 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.
> 
> I will take a look at the tests.  It would be good to have a unit test
> to cover this situation anyway, and you may be able to put one together
> faster than I

Well, not in form of a unit test, but attached is a piece of code that 
reproduces a crash nevertheless (at least for me under R5). It is more or 
less an extract of the BAppFileInfo unit test that crashes, but as it 
seems, we have some kind of memory corruption, since the crash happens in 
the last FindString() in main, but it only happens, if the static helper 
function is invoked.

The crash in the BNodeInfo unit test (in memcpy() indirectly invoked from 
Unflatten()) I was not able to track down. When I tried to isolate it, it 
disappeared. I just hope, it is caused by the same bug responsible for the 
memory corruption for the other problem.

> >> 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.
> 
> It is less than intuitive, no doubt there, although I was pleasantly
> surprized last night to find that even after all this time (I'd guess
> it's been about a year), the code still makes sense to me.  I will try
> to fix it as-is so as to get you up and running ASAP.

Thanks.

CU, Ingo


#include <Application.h>
#include <Entry.h>
#include <Message.h>

static
void
IsAppPreRegistered()
{
        BMessage request;
        entry_ref ref(0, 0, ".");
        request.AddRef("ref", &ref);
}

void
main()
{
        IsAppPreRegistered();
        BMessage testTypes1;
        testTypes1.AddString("types", 
"application/x-vnd.obos.app-file-info-test1");
        testTypes1.AddString("types", 
"application/x-vnd.obos.app-file-info-test2");
        const char *type;
        testTypes1.FindString("types", 2, &type);
}

Other related posts: