VMD-L Mailing List

From: John Stone (johns_at_ks.uiuc.edu)
Date: Fri Apr 03 2020 - 09:24:28 CDT

There was a bug that is fixed in the current src code. I'll get you
a new tarball shortly if you're not using CVS to stay in sync...

Best,
  John

On Fri, Apr 03, 2020 at 01:18:01PM +0200, FX wrote:
> Hello,
>
> A segfault was reported to me that occurs with my 64-bit macOS build, when drawing an isosurface for a cube file (which you can download at https://www.dropbox.com/s/g4oh8w0ih3xnlqe/cluster-SPIN_DENSITY-1_0.cube?dl=0)
>
> Yet I look at the segfault and I don???t see how it could be mac-specific or 64-bit-specific. The backtrace is:
>
> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x10f2bc000)
> frame #0: 0x00000001001110d5 VMD`DrawMolItem::draw_volume_isosurface_points(this=<unavailable>, v=0x0000000100d5a070, isovalue=0, stepsize=1, thickness=<unavailable>) at DrawMolItemVolume.C:337:23 [opt]
> 334 // draw perf gain here by eliminating them...
> 335 printf("### %d/%d\n", idx, lastgrid);
> 336 cols[idx ] = cp[0];
> -> 337 cols[idx+1] = cp[1];
> 338 cols[idx+2] = cp[2];
> 339
> 340 idx+=3;
> Target 0: (VMD) stopped.
> (lldb) bt
> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x10f2bc000)
> * frame #0: 0x00000001001110d5 VMD`DrawMolItem::draw_volume_isosurface_points(this=<unavailable>, v=0x0000000100d5a070, isovalue=0, stepsize=1, thickness=<unavailable>) at DrawMolItemVolume.C:337:23 [opt]
> frame #1: 0x00000001000f7a58 VMD`DrawMolItem::create_cmdlist(this=<unavailable>) at DrawMolItem.C:386:7 [opt]
> frame #2: 0x00000001000f28dc VMD`Displayable::draw_prepare(this=0x00000001042aee00) at Displayable.C:261:3 [opt]
> frame #3: 0x00000001000f28ff VMD`Displayable::draw_prepare(this=0x0000000106854c00) at Displayable.C:267:29 [opt]
> frame #4: 0x00000001000f28ff VMD`Displayable::draw_prepare(this=0x0000000103b7c250) at Displayable.C:267:29 [opt]
> frame #5: 0x000000010017d785 VMD`Scene::prepare(this=0x0000000103b78e00) at Scene.C:396:15 [opt]
> frame #6: 0x0000000100195c12 VMD`VMDApp::VMDupdate(this=0x0000000100f0ae50, check_for_events=<unavailable>) at VMDApp.C:837:27 [opt]
> frame #7: 0x00000001001ca205 VMD`main(argc=<unavailable>, argv=<unavailable>) at vmdmain.C:93:16 [opt]
>
> and the crash occurs because vmd is trying to write past the end of the colors buffer:
>
> (lldb) p idx
> (int) $0 = 31743
> (lldb) p colors
> (ResizeArray<float>) $1 = {
> data = 0x000000010f3b9000
> sz = 30003
> currSize = 0
> }
>
>
> I have tried to understand the logic in DrawMolItem::draw_volume_isosurface_points, but I fail:
>
> - centers and colors are ResizeArray???s
> - they are extended by around line 302, based on a comparison on centers.num(), i.e. the *actual* size of the ResizeArray (not the space allocated)
> - because the code below does not use the C++ methods of ResizeArray, but writes directly into the buffers, colors.num() and centers.num() always return 0
> - therefore the buffer are always extended??? it shouldn???t crash, but it???s weird to do it that way
> - the extend code is relying on actual data size to copy, which isn???t correctly updated (because direct access to the buffers). So if the data did extend, it would be crap anyway
> - but extend also takes into account only the current size of data stored, which isn???t updated: which is why after the first extend, further calls are no-ops, and we end up writing past the end of the array
>
> Maybe I missed something, because I really wonder how this could ever work? Help is welcome.
>
> Thanks,
> FX 

-- 
NIH Center for Macromolecular Modeling and Bioinformatics
Beckman Institute for Advanced Science and Technology
University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
http://www.ks.uiuc.edu/~johns/           Phone: 217-244-3349
http://www.ks.uiuc.edu/Research/vmd/