VW 7.2 BUG found ???

Hi
can anybody please shed some light on this more than peculiar behavior?
I debugged as far as possible, but it seems to be a VW bug. I have some
memory allocated for communication with a DLL:

allocateMemory

1 to: 3 do: [:i | pointers at: i put: (CIntegerType int malloc)].
pointers at:  4 put: (CLimitedPrecisionRealType double malloc: rows).
pointers at:  5 put: (CIntegerType int malloc: rows).
pointers at:  6 put: (CLimitedPrecisionRealType double malloc: columns).
pointers at:  7 put: (CLimitedPrecisionRealType double malloc: columns).
pointers at:  8 put: (CLimitedPrecisionRealType double malloc: columns).
pointers at:  9 put: (CIntegerType int malloc: columns+1).
pointers at: 10 put: (CIntegerType int malloc: nonZeros).
pointers at: 11 put: (CLimitedPrecisionRealType double malloc: nonZeros).

"pointers" is just a (Smalltalk) array to collect all pointers. The DLL writ
es
(integers and doubles) to the memory allocated, I extract the data and put i
t in
some Smalltalk native arrays and then try to free the memory:

freeMemory
"        pointers do: [:each | each free] "
(pointers at: 1) free.
(pointers at: 2) free.
(pointers at: 3) free.
(pointers at: 4) free.
(pointers at: 5) free.
(pointers at: 6) free.
(pointers at: 7) free.
"	(pointers at: 8) free. "
(pointers at: 9) free.
(pointers at:10) free.
(pointers at:11) free.

When the code '(pointers at: 8) free' is executed, VW crashes!!! If it is
commented out (like above), everything works fine, except of course I now go
t a
memory leak!
What's going on? I tried the best I could, but am stuck...

Thanks
Mike

P.S. Crashes in this context means one gets the well-known Windows Dialog: "
The
instruction at '...' referenced memory at '...'. The memory could not be
'written'. Click OK to terminate.

If I take your example and run it directly, just allocating the memory,
then de-allocating it, it runs fine. I did have to make up numbers fo
rows, columns, and nonZeros. This was in VW 7.2.1 on Windows XP
Professional. You don't mention your version or platform.

This suggests to me that either there is more to the example, or that the
DLL is manipulating the memory in a way that Smalltalk's attempt to free
it is causing an error. The most obvious would be that it had already
been freed, but C has a host of ways to mess up memory. A useful
debugging technique might be to comment out all of the C code, have VW
just call the DLL to do nothing, then free the memory, then progressively
uncomment more of the DLL, which might narrow down a problem area (and if
it happens when the DLL does nothing, that's a stronger suggestion that
the problem is in VW).

Michael Bielser <mike.bielser@ior.unizh.ch> wrote in
news:4108B794.6070203@ior.unizh.ch:

> Hi
> can anybody please shed some light on this more than peculiar
> behavior? I debugged as far as possible, but it seems to be a VW bug.
> I have some memory allocated for communication with a DLL:
>
> allocateMemory
>
> 1 to: 3 do: [:i | pointers at: i put: (CIntegerType int malloc)].
> pointers at:  4 put: (CLimitedPrecisionRealType double malloc: rows).
> pointers at:  5 put: (CIntegerType int malloc: rows).
> pointers at:  6 put: (CLimitedPrecisionRealType double malloc:
> columns). pointers at:  7 put: (CLimitedPrecisionRealType double
> malloc: columns). pointers at:  8 put: (CLimitedPrecisionRealType
> double malloc: columns). pointers at:  9 put: (CIntegerType int
> malloc: columns+1). pointers at: 10 put: (CIntegerType int malloc:
> nonZeros). pointers at: 11 put: (CLimitedPrecisionRealType double
> malloc: nonZeros).
>
> "pointers" is just a (Smalltalk) array to collect all pointers. The
> DLL writes (integers and doubles) to the memory allocated, I extract
> the data and put it in some Smalltalk native arrays and then try to
> free the memory:
>
> freeMemory
> "        pointers do: [:each | each free] "
>      (pointers at: 1) free.
>      (pointers at: 2) free.
>      (pointers at: 3) free.
>      (pointers at: 4) free.
>      (pointers at: 5) free.
>      (pointers at: 6) free.
>      (pointers at: 7) free.
> "     (pointers at: 8) free. "
>      (pointers at: 9) free.
>      (pointers at:10) free.
>      (pointers at:11) free.
>
> When the code '(pointers at: 8) free' is executed, VW crashes!!! If it
> is commented out (like above), everything works fine, except of course
> I now got a memory leak!
> What's going on? I tried the best I could, but am stuck...
>
> Thanks
> Mike
>
> P.S. Crashes in this context means one gets the well-known Windows
> Dialog: "The instruction at '...' referenced memory at '...'. The
> memory could not be 'written'. Click OK to terminate.
>
>



--
Alan Knight [|], Cincom Smalltalk Development
knight@acm.org
aknight@cincom.com
http://www.cincom.com/smalltalk

"I believe that many of the systems we build today in Java would be
better built in Smalltalk and Gemstone." -- Martin Fowler, JAOO 2003

Hi Alan
thank you for your suggestions. I'm using VW 7.2 on Win2000
Professional, by the way. What makes this even stranger is that it
worked without a hitch with a previous version of the DLL (might suggest
the DLL is the culprit, but I don't think so: why does the free work
with 'pointer at:6' and 'pointer at:7' but not with 'pointer at:8'; they
allhave the same array).
Anyway, I'll try the procedure you suggested and will comment. In the
meantime thanks a lot!
Mike

P.S. I didn't write the DLL, so it'll take some time


Alan Knight wrote:
> If I take your example and run it directly, just allocating the memory,
> then de-allocating it, it runs fine. I did have to make up numbers fo
> rows, columns, and nonZeros. This was in VW 7.2.1 on Windows XP
> Professional. You don't mention your version or platform.
>
> This suggests to me that either there is more to the example, or that the
> DLL is manipulating the memory in a way that Smalltalk's attempt to free
> it is causing an error. The most obvious would be that it had already
> been freed, but C has a host of ways to mess up memory. A useful
> debugging technique might be to comment out all of the C code, have VW
> just call the DLL to do nothing, then free the memory, then progressively
> uncomment more of the DLL, which might narrow down a problem area (and if
> it happens when the DLL does nothing, that's a stronger suggestion that
> the problem is in VW).
>

Well, in the meantime I got a new version of the DLL where the function
in question has been uncommented. I checked my code and freeing the
memory works again! So, like you guessed, the DLL is the culprit. Now we
have to hunt down what exactly causes the problem. I'll let you know...


>
> Alan Knight wrote:
>
> If I take your example and run it directly, just allocating the
> memory, then de-allocating it, it runs fine. I did have to make up
> numbers fo rows, columns, and nonZeros. This was in VW 7.2.1 on
> Windows XP Professional. You don't mention your version or platform.
>
> This suggests to me that either there is more to the example, or that
> the DLL is manipulating the memory in a way that Smalltalk's attempt
> to free it is causing an error. The most obvious would be that it had
> already been freed, but C has a host of ways to mess up memory. A
> useful debugging technique might be to comment out all of the C code,
> have VW just call the DLL to do nothing, then free the memory, then
> progressively uncomment more of the DLL, which might narrow down a
> problem area (and if it happens when the DLL does nothing, that's a
> stronger suggestion that the problem is in VW).
>

Looks like the problem is solved: Within the function in question, the
DLL initialized an 'int' but wrote a 'long int'. This caused a problem
when freeing the memory. Why it happened exactly at the 8th element of
the array, nobody knows (could have also happened at the 6th or 7th
element). I'm glad it's not a VW bug. Thanks again for the excellent
debugging tip!


P.S. My post below should read: "... the function in question has been
commented" (NOT uncommented of course; it was late night...)


Michael Bielser wrote:
> Well, in the meantime I got a new version of the DLL where the function
> in question has been uncommented. I checked my code and freeing the
> memory works again! So, like you guessed, the DLL is the culprit. Now we
> have to hunt down what exactly causes the problem. I'll let you know...
>
> 

Michael Bielser <mike.bielser@ior.unizh.ch> wrote:

>Looks like the problem is solved: Within the function in question, the
>DLL initialized an 'int' but wrote a 'long int'. This caused a problem
>when freeing the memory. Why it happened exactly at the 8th element of
>the array, nobody knows (could have also happened at the 6th or 7th
>element). I'm glad it's not a VW bug. Thanks again for the excellent
>debugging tip!
>
>
>P.S. My post below should read: "... the function in question has been
>commented" (NOT uncommented of course; it was late night...)

Sure, with the way memory protection works such as programming in C, it
isn't guaranteed to cause protection faults for every flaw and can occur
later.  This of course, makes debugging much more fun, and why C is a far
more fun programming language to work in.  ;)

There also are tools like this:
http://www.microquill.com/heapagent/index.html
That provide the ability to catch some of these flaws earlier.

Ian

---
http://www.upright.net/ian/