Wojtek,
thanks for your mail. I guess in my case I do not have problems with parameter passing to C routines because on one PC the
call always works, on another PC it works sometimes and sometimes not.
But your presentation was a BIG help to me some years ago when I started to learn how to do parameter passing to C routines.
So, anyway, thanks a lot for this great introduction.
Romiras,
maybe your mail put me in the right direction.
Today I went to the machine with the DLL call sometimes working and sometimes does not.
I discovered that it always works when I start my application right after startup of BlackBox and before allocation of much dynamic memory.
In this case the status line of BB tells it had allocated arount 800 kBytes of memory right after startup.
To trigger the allocation of memory before starting my application I compile all modules of my project (about 30).
After compilation the status line shows about 5 MBytes of allocated memory. Starting the application now will produce the trap window:
illegal memory read (ad = 15FEAB80H)
?(???(?(?(?(?(???(?(???(?(?(?(?? 01X
Opening the properties window of the PC shows
Windows XP Professional
Version 2002 Service Pack 3
Genuine Intel CPU
T2500 {([at]})nowhere.xy
3.24 GB of RAM
Physical Address Extension
Having this found out I went to my office PC where the trap never happened (up to now).
It's properties are
Windows XP Professional
Version 2002 Service Pack 3
Pentium Dual-Core CPU
E5400{([at]})nowhere.xy
3.21 GB RAM
Physical Address Extension
I'm able to compile my application with and without calls to the DLL to be able to do debugging on PCs which don't have the DLL installed.
I ran BlackBox on my office PC with the task manager opened to watch allocated memory.
Running the application without DLL calls:
memory display in task manager: 15.920 K; allocated memory in BB status line: 1.287 MBytes; counts up to 3.6 MBytes until garbage collection
Running the application with DLL calls:
memory display in task manager: 35.788 K; increases to 36.768 K; memory in BB status line: 1.33 Mbytes, counts up to 4.1 MBytes until garbage collection
I run BlackBox 1.6-rc5 and the effect shows up on XP machines.
It also appears on a Windows 7 PC where I never succeeded to call the DLL without the trap.
Starting BB on this machine without calling the application allocates more than 2 MBytes of memory (status line of BB).
Starting BB on a XP machine without calling the application allocates less than 900 KBytes of memory.
This is what I could find out today. But I have still no idea how to solve the problem.
Any help appreciated very much.
Thanks and best regards,
Rainer
Am 06.10.2012 um 21:45 schrieb Romiras:
Trap "illegal memory read" (#203) may point to problem with garbage collection in module Kernel. One of possible reasons is incorrect declaration of foreign interface (pointer arithmetics with SYSTEM), but it is not a your case.
An error is occurred when GC is tries to collect garbage:
1. when program tries to allocate memory by NEW
2. when too many files open
Does program crashes immediately when calling DLL?
Is program work intensively with dynamic memory? "Memory hungry" program?
Questions about environment:
1. In which version of BlackBox trap occurred?
2. In which version of OS?
Try to apply GC patches to Kernel from topic "Windows 7" in mailing list (see last messages of user luowy). It may help.
2012/10/6 Rainer Neubauer <neubauer.rainer{([at]})nowhere.xy
Hi all,
I have a serious problem when calling a DLL procedure.
The DLL is a third party product (an API to a big relational data base) and is in deployment in the
production area in the company I am with on many systems.
It is used by many programms written in different languages (C, C++, Visual Basic).
Calling the DLL procedures with CP works well on some systems. On other systems I
get an error message or even a trap when I call the initialisation routine of the DLL
which has to be the first call before using the DLL.
The initialisation routine has an input parameter (a string), an output parameter (a pointer
to a string) and returns an integer value. I expect the parameter passing from CP to the
routine to contain no error because it works on some systems.
On some systems calling the initialisation routine produces a trap looking like this:
illegal memory read (ad = 15FEAB80H)
?(???(?(?(?(?(???(?(???(?(?(?(?? 01X
<system> (pc=7711E3BEH, fp=0028E5CCH)
<system> (pc=7711E022H, fp=0028E5E4H)
<system> (pc=74E914DCH, fp=0028E5F8H)
<system> (pc=7C342189H, fp=0028E640H)
<system> (pc=6DA140B0H, fp=64CA8000H)
This trap window looks different from the usual traps I get when I e.g. try to access memory with a NIL pointer.
Does anybody have an idea what the trap information tells ?
- does it tell my input string to the DLL procedure may be invalid ?
- does it tell the DLL code has an internal problem ?
- does it tell an invalid memory access with the output parameter ?
When I put a HALT statement right after the DLL call the HALT will not be executed.
It would be helpful to have any idea about what is going on when I want to ask the vendor of the DLL for a solution.
Thanks for any hints and best regards,
Rainer
---- To unsubscribe, send a message with body "SIGNOFF BLACKBOX" to LISTSERV{([at]})nowhere.xy
---- To unsubscribe, send a message with body "SIGNOFF BLACKBOX" to LISTSERV{([at]})nowhere.xy
---- To unsubscribe, send a message with body "SIGNOFF BLACKBOX" to LISTSERV{([at]})nowhere.xy
Received on Mon Oct 08 2012 - 17:19:00 UTC