Hi Lilantha,
Thanks for the info. The /MD /MT distinction is not as clear as I thought... The anomaly still remains though and the root of the problem seems to be passing memory pointers across DLL boundaries (i.e where objects are created in one DLL and used by another, because the heaps are different, the object cannot be deleted by the user). I thought about passing the object back to its creator for deletion, but this could be messy. The other though I had was to create the object where it is to be used and then to pass the pointer to the creator/populator method, but this is even more messy. Have you experienced these sorts of problems with Axis or have you been building your applications with the /MD flag rather than the /MT flag?
Thanks also for the info on your project. It's always helpful to know how others are using Axis ;-)
Best Regards,
Fred Preston.
| "Lilantha Darshana" <[EMAIL PROTECTED]>
09/26/2005 02:39 PM
|
To: "Apache AXIS C User List" <axis-c-user@ws.apache.org> cc: Subject: RE: /MD and /MT compiler options on MSVC6 |
Hi Fred,
It seems you are referring to MSVS .NET reference pages since, the URLs you have given:
1. http://msdn.microsoft.com/library/default.asp?url="">
MSDN Home > MSDN Library > Development Tools and Languages > Visual Studio .NET > Visual C++ > Building a C/C++ Program > C/C++ Building Reference > Compiling a C/C++ Program > Compiler Options > Compiler Options Listed Alphabetically
2. http://msdn.microsoft.com/library/default.asp?url="">
MSDN Home > MSDN Library > Development Tools and Languages > Visual Studio .NET > Visual C++ > Reference > Visual C++ Libraries > Run-Time Library Reference
Instead of above URLs please refer to: MSVC6 reference pages at:
http://msdn.microsoft.com/library/default.asp?url="">
and
http://msdn.microsoft.com/library/default.asp?url="">
Options /MT & /MD are used for both DLLs and for executable binaries. Only difference is /MT links with thread
safe versions of static libs and /MD links shared version of thread safe libs at runtime.
I’m not pretty sure what exactly the cause for the test failure though.
As a solution to the defect AXISCPP-149, how about having a destructor in the struct to delete m_Array member.
According to my knowledge there are so many customers out there who use MSVC6 still. Example my project at
Siebel, and we have not planned any soon to replace our version with MSVC7 since we have lots of customers who
we need to support with the application developed with this version. Therefore I believe MS will continue to support
that version for some time.
Thanks
-Lilantha
From: Fred Preston [mailto:[EMAIL PROTECTED]
Sent: Monday, September 26, 2005 5:16 AM
To: Apache AXIS C User List
Subject: RE: /MD and /MT compiler options on MSVC6
Hi Lilantha,
I only have MSVC6 on my machine.
I took the load library information from the MSVC information pages on the Microsoft website (see links in previous e-mail). This is the description for the /MD compiler option...
|
|
I don't think I've miss quoted... I agree with what you are saying, but here is my problem. When I run the tests using the build options used to build the DLL's, the majority run without a problem. But, when I run the same tests after building then with the /MT rather than the /MD option, I get exceptions. These exceptions must be down to the underlying differences between the compiler options and my point is;- The tests should not be built using the /MD flag as they are not DLLs. If the 'proper' flag is used to build these tests, then exceptions are caused because of the different linked libraries. If we have this incompatibility between libraries then this could potentially be a big problem for a customer and my suggestion was that either everything is built with the /MD flag or we do what a lot of customers have already done and move up (as suggested in the Microsoft documentation) to MSVC7. (Do MS still support MSVC6 and if they do, how long will they continue to do so?).
Regards,
Fred Preston.
| "Lilantha Darshana"
<[EMAIL PROTECTED]>
09/23/2005 09:45 PM
| To: "Apache AXIS C User List" <axis-c-user@ws.apache.org>, axis-c-dev@ws.apache.org cc: Subject: RE: /MD and /MT compiler options on MSVC6 |
First question is why are you trying to link with both msvcrt and msvcr71 CRT libs at the same time?
If we use /MT option that mean we link statically to multi-threaded library so the generated object file size
is large. But if we use /MD we link to a static lib – having LoadLibrary() method and respective code to get the
ProcAddress() of called functions – that is having only the tiny code for loading functions from a
shared lib at runtime. So the final object code is small.
Check your lib path and linker path to see whether you are using anything from .NET instead of all libs from MDVC6.
Thanks
-Lilantha
From: Fred Preston [mailto:[EMAIL PROTECTED]
Sent: Friday, September 23, 2005 7:16 AM
To: axis-c-dev@ws.apache.org; axis-c-user@ws.apache.org
Subject: /MD and /MT compiler options on MSVC6
Hi All,
I'd like to discuss the /MD and /MT compiler options available on MSVC6.
The AxisClient DLLs are built with the /MD option that instructs the DLLs to use both multi-threaded and DLL specific options within the standard header files. It also tells the compiler to put the MSVCRT.lib into the object file and applications are statically linked to it. The DLLs are dynamically linked to msvcprt.lib while still dynamically linked to the main C runtime via msvcrt.lib.
Now, If I use the ant scripts to build one of the tests (such as AxisBench) it will build and run successfully. What I hadn't realised up to now is that when I use the ant scripts, it uses the same compiler options to build the tests as it does to build the Axis DLLs and so the tests are being built with the /MD compiler option. I am looking at AXISCPP-149, trying to work out the best way to clean up the 'delete <stub_generatred_object>' problems with complex objects and needed to debug a couple of tests to see what is missing in the delete (this is a bit of an aside, but helps set the context). So I created a new MSVC project using the test generated framework for AxisBench and compiled the project using the 'normal' application build options (i.e. /MT for multi-threaded application). Now, using the /MT option causes the compiler to place the LIBCMT.lib into the object file. When the 'release' version of the application was built, it was immediately obvious that I had two different exe's because the ant built one was 56K whilst the MSVC built one was 208K. So what does this mean? Well, I've already said that the ant built exe runs, but the MSVC built one with the /MT option failed with the following messages:-
Unknown Exception occurred.
Unknown Exception occurred.
Unknown Exception on clean up:
Unknown Exception occurred.
Unknown Exception on clean up:
It is failing inside BenchDataType::Axis_Deserialize_BenchDataType( BenchDataType * param, IWrapperSoapDeSerializer * pIWSDZ) at the beginning of the method when it tries to delete 'count' which is an object that is passed back after being created within the deserialiser (across the DLL boundary? - more on this later...). This is because 'count' is not known to the heap and it reports the following error:-
HEAP[AxisBench.exe]: Invalid Address specified to RtlFreeHeap( 00340000, 0057B2D8) <-- obviously the numbers will change!
So, I looked at the compiler options and discovered that ant was building the applications with the /MD option. When I tried this option, the exe size was the same and the application ran without a problem.
So, what does this mean? I started with the libraries... Looking at http://msdn.microsoft.com/library/default.asp?url="" and http://msdn.microsoft.com/library/default.asp?url="" the LIBCMT.lib is a multi-threaded, static link library and MSVCRT.lib is a multi-threaded dynamic link library... "Humm, so what?", I thought, but I kept reading... The very last sentence of the "What problems exist if an application uses both msvcrt and msvcr71?" is very revealing, "...If your DLLs pass CRT resources across the library boundary, you will encounter issues with mismatched CRTs...". I would take this to be memory issues, such as heap, etc. And it finishes with "...recompile your project with Visual C++ .NET.".
So, we have potential problems with different libraries using MSVC6 and Microsoft is suggesting that if we are finding problems, then we need to move to '.NET' which I think implies that we should move to MSVC7 (which can be found on MSVC 2003 .NET). Interesting...
RECOMMENDATIONS:
1. If you are having similar problems as I did running AxisClient, try using the /MD rather than /MT compiler flag.
2. AxisClient should be built using MSVC7 to avoid future library inconsistencies.
Regards,
Fred Preston.
_______________
Siebel
IT'S ALL ABOUT THE CUSTOMER
Visit www.siebel.com
This e-mail message is for the sole use of the intended recipient(s) and
contains confidential and/or privileged information belonging to Siebel
Systems, Inc. or its customers or partners. Any unauthorized review, use,
copying, disclosure or distribution of this message is strictly prohibited.
If you are not an intended recipient of this message, please contact the
sender by reply e-mail and destroy all soft and hard copies of the message
and any attachments. Thank you for your cooperation.
