I am creating a program (A) which output is a text file (F.txt). This file is then read by other program I have created (B) which does some further analysis with the data from file (F) and produces some results...
I compiled A.exe and B.exe and the whole system runs nicely. I can execute A.exe, get F.txt, then run B.exe and get the final results.
I modified A.exe to call directly B.exe at the end of its execution, once F.txt is created. Everything runs fine.
Then I converted B.exe into C.dll which is linked from A.exe, but still does the same as B.exe. C.dll only have one more function, only one exported and linkable from A.exe which is very much the same to the main function of B.exe. This is to allow A.exe to trigger the execution of the code in B without having to execute a system command.
The problem is that sometimes I got a memory read error from C.dll when it is called within A.exe: A.exe successfully produces F.txt then links C.dll, which reads the content of the file F.txt fine but it crashes during the analysis of the data. OK, I thought there must be a problem in A.exe that produces a wrong file F.txt that C.dll reads and makes it to crash during the analysis. But if I take that same file F.txt and run it with B.exe, it works fine!. Even more, if I create a simple program D.exe that also links the same library C.dll but the only thing that it does is to pass the arguments of the main function of D.exe to C.dll so that I can use it to run the DLL passing the location and name of the file F.txt that was created with A.exe, the analysis is done OK (with the same file F.txt!).
So C.dll crashes when processing a file F.txt that was produced by A.exe when directly linked from A.exe, but if F.txt is processed by B.exe or D.exe(which links C.dll) there is no problem. Additionally not all the F.txt files produced by A.exe makes C.dll to crash. None of them crashes if run with B.exe or D.exe...
Sorry for the long post. Does anybody have a clue of what it may be happening?
Many thanks in advance.
Regards,
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, I am. The problem happens in a completely different part of the calculation... Actually it happens either at the very end of the program when all the calculation have finished (then, it freezes and exit the application with a system error) or within the analysis done by an static library that have been working without problems for more than 3 years. Additionally, just to remember that the very same C.dll working with the very same file F.txt produced by A.exe, works perfectly fine when launched within D.exe that only takes the file F.txt location and passes it to C.dll for the calculation (then, even with the long #define directives, everything works fine...) Or the case of B.exe, using the same static library... Also fine. So this seems quite strange and possibly due to a weird interaction between long definitions of #define directives and some allocation of memory at runtime when the program/library is launched. I admit this is a bit strange and this is why I am checking with the experts. It maybe something completely different, but it is important to keep in mind that the very same code with the very same input file (F.txt) works right or wrong only depending on what program at runtime is calling the library...
Thanks again for your comments.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
(2) Programs A.exe and B.exe (C.dll) are very long... And any simpler program does not reproduce this problem... The same code works right and wrong... Don't know how to add value to basic 2 but open to suggestions
(3) As with 2, open to suggestions...
Many thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've never seen a limitation on that but I doubt I've ever used a string quite that long. I do have some code with a #define with a few dozen lines concatenated with '\' characters such that the entire #define is probably longer than 2000 characters but no individual string is. Are you sure it's not the place where you're using MyString that's causing the problem?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear all,
I am creating a program (A) which output is a text file (F.txt). This file is then read by other program I have created (B) which does some further analysis with the data from file (F) and produces some results...
I compiled A.exe and B.exe and the whole system runs nicely. I can execute A.exe, get F.txt, then run B.exe and get the final results.
I modified A.exe to call directly B.exe at the end of its execution, once F.txt is created. Everything runs fine.
Then I converted B.exe into C.dll which is linked from A.exe, but still does the same as B.exe. C.dll only have one more function, only one exported and linkable from A.exe which is very much the same to the main function of B.exe. This is to allow A.exe to trigger the execution of the code in B without having to execute a system command.
The problem is that sometimes I got a memory read error from C.dll when it is called within A.exe: A.exe successfully produces F.txt then links C.dll, which reads the content of the file F.txt fine but it crashes during the analysis of the data. OK, I thought there must be a problem in A.exe that produces a wrong file F.txt that C.dll reads and makes it to crash during the analysis. But if I take that same file F.txt and run it with B.exe, it works fine!. Even more, if I create a simple program D.exe that also links the same library C.dll but the only thing that it does is to pass the arguments of the main function of D.exe to C.dll so that I can use it to run the DLL passing the location and name of the file F.txt that was created with A.exe, the analysis is done OK (with the same file F.txt!).
So C.dll crashes when processing a file F.txt that was produced by A.exe when directly linked from A.exe, but if F.txt is processed by B.exe or D.exe(which links C.dll) there is no problem. Additionally not all the F.txt files produced by A.exe makes C.dll to crash. None of them crashes if run with B.exe or D.exe...
Sorry for the long post. Does anybody have a clue of what it may be happening?
Many thanks in advance.
Regards,
Yes, I am. The problem happens in a completely different part of the calculation... Actually it happens either at the very end of the program when all the calculation have finished (then, it freezes and exit the application with a system error) or within the analysis done by an static library that have been working without problems for more than 3 years. Additionally, just to remember that the very same C.dll working with the very same file F.txt produced by A.exe, works perfectly fine when launched within D.exe that only takes the file F.txt location and passes it to C.dll for the calculation (then, even with the long #define directives, everything works fine...) Or the case of B.exe, using the same static library... Also fine. So this seems quite strange and possibly due to a weird interaction between long definitions of #define directives and some allocation of memory at runtime when the program/library is launched. I admit this is a bit strange and this is why I am checking with the experts. It maybe something completely different, but it is important to keep in mind that the very same code with the very same input file (F.txt) works right or wrong only depending on what program at runtime is calling the library...
Thanks again for your comments.
The basic 3 for this thread:
(1) Version 4.9.9.2, with Windows XP.
(2) Programs A.exe and B.exe (C.dll) are very long... And any simpler program does not reproduce this problem... The same code works right and wrong... Don't know how to add value to basic 2 but open to suggestions
(3) As with 2, open to suggestions...
Many thanks.
What is the difference in the f.txt files, one that crashes and one that doesn't? Special characters, length, size????
DLL_PROCESS_ATTACH or DLL_THREAD_ATTACH?
just guessing without seeing code.
I believe it is DLL_PROCESS_ATTACH.
I have been tracking down potential issues and have managed to avoid the problem (so far) by changing some #define directives in my code.
I had in the code instructions such as:
define MyString "...long string of characters up to 2000 elements..."
When I have changed them to:
define MyString "...shorter string with no more than 100 characters..."
It seems that the problem is gone.
Do you know if there is any limitation with the length of the #define preprocessor directives...?
Many thanks.
I've never seen a limitation on that but I doubt I've ever used a string quite that long. I do have some code with a #define with a few dozen lines concatenated with '\' characters such that the entire #define is probably longer than 2000 characters but no individual string is. Are you sure it's not the place where you're using MyString that's causing the problem?