> Yes. Recall that if one unit test fails, the rest are still run, so if > that test sets something up that the others expect they will fail > also. > > So the real problem is the memory protection fault.
Man, that was a fun one. com-query-interface was calling IUnknown::QueryInterface with a <void*> byte-array to receive the resulting interface pointer, which works great for regular C- implemented COM interfaces. But when the COM interface is calling back into a Factor object, as in the windows.com tests, every so often a GC would occur during the alien-callback, which moves the byte-array out from under the callback without updating what the callback sees as just a dumb alien pointer. So the QueryInterface implementation on +guinea-pig-implementation+ was intermittently writing its result to reclaimed memory where the out byte-array used to be, then add-ref'ing the interface and returning S_OK as if everything was fine. com-query- interface then sees the null pointer in the byte-array, which in its new location was never written to, but proceeds as if everything's fine because it received an OK return value. The first thing to actually try to use the interface pointer of course segfaults, causing the first test failure, and the interface subsequently leaks because it was never released, causing the second failure. I changed com- query-interface to malloc the out buffer so that the GC won't move it, which avoids the problem,\. This seems like it could be a bigger issue overall. Anywhere Factor calls what it thinks is a C function but is really an alien-callback using byte-arrays as arguments, the GC can potentially move those byte- arrays without updating the alien-callback's corresponding parameters. (Maybe this is a known problem, and I just didn't read that page of the documentation.) Would it be a good idea to disable GC in the VM any time an alien-callback is running? In the meantime, my fix for windows.com is in my git repo. I also refactored windows.com.wrapper to make the code a little easier to follow; instead of pump-and-dumping gensyms for the callbacks it compiles, it now generates words in the "windows.com.wrapper.callbacks" vocab, so you can look at the words and see what code the wrapper generated. -Joe ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
