[Vm-dev] instantiateClass:indexableSize: upper limit?

[David T. Lewis]

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 at 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/Makefile.example?revision=3753&view=markup
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