On Fri, Jun 23, 2017 at 09:45:45AM -0700, Eliot Miranda wrote:
Hi Tom,
On Fri, Jun 23, 2017 at 1:35 AM, Tom Beckmann tomjonabc@gmail.com wrote:
Dear VM devs,
I'm trying to allocate a Bitmap of around 16MB size in a plugin via `interpreterProxy instantiateClass: interpreterProxy classBitmap indexableSize: size`. However, I always get NULL back. I already tried wrapping the primitive call in `retryWithGC:until:`, with the same effect. Running a normal `Bitmap new: 16000000` from a workspace works flawlessly.
I'm on a Ubuntu 16.04 64bit, running a squeak 32bit built from trunk.
Is there anything to watch out for? More precisely, I'm trying to copy the contents of an image buffer generated from a pdf via libpoppler at 144dpi to a new bitmap in squeak. The primitive and how I invoke it can be seen here: https://pastebin.com/9NCdnx2J (line 50 is the call in question)
Thanks in advance for any pointers!
I want to endorse what Bert said; allocating in the image is a much better approach. But I did want to explain what you're seeing, assuming you're using Spur (Squeak 5.x, Pharo 6).
I also want to endorse Bert's advice here. But by way of practical advice if you did really do need to debug your primitive:
Compile the VM with debugging enabled and compiler optimization disabled. Run the VM under a debugger (gdb or whatever). Put a breakpoint at the primitive function, and step through it to see where things are going wrong.
If you are dealing with a primitive that is called many times from the image, then just make a second copy of the primitive and give it a different name (so if you are working on #primitiveFoo, then make another #primitiveFoo2). You can then call that second copy from the image, and debug it when you hit the breakpoint in gdb.
You mentioned that you were working with "trunk" VM sources. If that refers to the interpreter VM, then in the makefile example at http://squeakvm.org/cgi-bin/viewvc.cgi/squeak/trunk/platforms/unix/cmake/Mak... you can use this to compile with debugging and no optimization:
CFLAGS_PARAM="--CFLAGS='-O0 -g'"
In Spur/Cog the equivalent is in the mvm scripts. Either way, the idea is to compile your plugin with debugging symbols enabled, and with all of the compiler optimizations turned off. Once you have that, you can poke around in the dgb debugger and see what is going wrong. Nine times out of ten it will turn out to be something you never would have guessed :-)
HTH, Dave