Chuck Messenger wrote:
> Mark Hammond wrote:
>
>
> > Try using the nsAllocator class - eg nsAllocator::Clone() should be used
> > instead of PL_strdup.
> >
> >> Another question: are there any particular compiler flags I need to
> >> use for my DLL? I'm on a Windows platform.
> >
> > If possible, you should try and use the makefile.win system used by
> > Mozilla - then the flags are taken care of for you. I *suspect* that
> > you are seeing a crash as you did not use /Md (or /MDd for debug builds)
> > meaning your code and xpcom itself were using different CRTL heaps.
> >
> > Mark
> >
>
> No joy. I tried using nsAllocator::Clone (now renamed to nsMemory)
> instead of PL_strdup. Still the same problem. I am using /MD and /MDd
> (for release/debug builds).
>
> I also tried adding all the defines which are used when compiling
> regular Mozilla .cpp files. Somewhere in the docs, it _says_ that you
> only need to define XP_WIN and XP_WIN32. However, just in case this
> isn't true, I added about 30 other defines.
>
> The result of this was that, when SelfRegisterDll() loads my dll, it
> complains that:
>
> The procedure entry point NS_CurrentThread could not be located
> in xpcom.dll
This is caused by compiling you component as DEBUG and running
against a RELEASE xpcom.dll. There is a mismatch in the debug
only code.
I didn't see any obvious crashers in the code you sent. The point
Mark made about being sure you are using the same heap as xpcom
is critical. Using nsMemory is the best way to ensure that.
The part...
if (*aErrStr) {
fs << " freeing aErrStr\n";
PL_strfree(*aErrStr);
*aErrStr = 0;
}
... is inapproriate since aErrStr is declared as 'out' and not
'inout'. So, no caller should be handing you a buffer that you
would be deleting. But, in this case the caller should be
xpconnect and it would not have set *aErrStr to a non-null value.
I'm thinking there is something else going on that the info you
are sharing does not uncover. I don't know what it is. If you
want to zip up the buildable files, I (or someone) might take a
closer look. Otherwise, you'll just have to debug through the
problem 'till you figure it out.
John.
>
> How do I fix that?
>
>
> - Chuck
>
