memory leak in volume() [message #92183] |
Tue, 27 October 2015 16:58  |
dg86
Messages: 118 Registered: September 2012
|
Senior Member |
|
|
Dear Folks,
The Volume() function appears to leak memory in IDL 8.5, leading to frequent
crashes under both Mac and GNU/linux (Mac: Yosemite 10.10.5, XQuartz 2.7.8;
Ubuntu 15.04 and 15.10). Running from the command line, a few calls to Volume() will
cause IDL to quit to the UNIX prompt with a Bus error: 10, which is indicative of a memory leak.
Crashes are more frequent with large data sets.
Once IDL has crashed this way the first time, restarting IDL and trying to create any function-graphics window will lead to another abrupt crash. The only way to fix this is to restart the X server, for instance by logging out and logging in again.
This is too bad because volumetric rendering is still one of the things that IDL does
better than the competition, at least IMHO.
TTFN,
David
|
|
|
Re: memory leak in volume() [message #92184 is a reply to message #92183] |
Wed, 28 October 2015 03:39   |
Helder Marchetto
Messages: 520 Registered: November 2011
|
Senior Member |
|
|
On Wednesday, October 28, 2015 at 12:58:12 AM UTC+1, David Grier wrote:
> Dear Folks,
>
> The Volume() function appears to leak memory in IDL 8.5, leading to frequent
> crashes under both Mac and GNU/linux (Mac: Yosemite 10.10.5, XQuartz 2.7.8;
> Ubuntu 15.04 and 15.10). Running from the command line, a few calls to Volume() will
> cause IDL to quit to the UNIX prompt with a Bus error: 10, which is indicative of a memory leak.
> Crashes are more frequent with large data sets.
>
> Once IDL has crashed this way the first time, restarting IDL and trying to create any function-graphics window will lead to another abrupt crash. The only way to fix this is to restart the X server, for instance by logging out and logging in again.
>
> This is too bad because volumetric rendering is still one of the things that IDL does
> better than the competition, at least IMHO.
>
> TTFN,
>
> David
Hi David,
I've just tried something using some real data I had 512x509x230 on my windows machine:
IDL> help, bytCube
BYTCUBE BYTE = Array[512, 509, 230]
IDL> !version
{
"ARCH": "x86_64",
"OS": "Win32",
"OS_FAMILY": "Windows",
"OS_NAME": "Microsoft Windows",
"RELEASE": "8.5",
"BUILD_DATE": "Jul 7 2015",
"MEMORY_BITS": 64,
"FILE_OFFSET_BITS": 64
}
Then I just made 50 time a volume:
outStrings = strarr(50)
for i=0,49 do begin & v = volume(bytCube, /ZERO_OPACITY_SKIP, RENDER_EXTENTS=0, hints=3, /AUTO_RENDER) & v.close & help, /memory, output=out & outStrings[i] = out[0] & endfor
;get the heap memory used into outUsedLon
outUsedStr = strsplit(outStrings,/extract)
outUsedLon = lonarr(50)
for i=0,49 do outUsedLon[i] = long((outUsedStr[i])[3])
p = plot(outUsedLon)
mx = max(outUsedLon)
mn = min(outUsedLon)
relChange = (mx-mn)/float(mx+mn)
print, 'Relative change = ', relChange
The result is a constantly increasing plot (there is some memory going lost somewhere), but the relative change is very small:
Relative change = 4.47812e-006
So at least in my case, I could not reproduce your problem.
Cheers,
Helder
|
|
|
Re: memory leak in volume() [message #92200 is a reply to message #92183] |
Wed, 28 October 2015 14:19   |
chris_torrence@NOSPAM
Messages: 528 Registered: March 2007
|
Senior Member |
|
|
On Tuesday, October 27, 2015 at 5:58:12 PM UTC-6, David Grier wrote:
> Dear Folks,
>
> The Volume() function appears to leak memory in IDL 8.5, leading to frequent
> crashes under both Mac and GNU/linux (Mac: Yosemite 10.10.5, XQuartz 2.7.8;
> Ubuntu 15.04 and 15.10). Running from the command line, a few calls to Volume() will
> cause IDL to quit to the UNIX prompt with a Bus error: 10, which is indicative of a memory leak.
> Crashes are more frequent with large data sets.
>
> Once IDL has crashed this way the first time, restarting IDL and trying to create any function-graphics window will lead to another abrupt crash. The only way to fix this is to restart the X server, for instance by logging out and logging in again.
>
> This is too bad because volumetric rendering is still one of the things that IDL does
> better than the competition, at least IMHO.
>
> TTFN,
>
> David
Hi David,
Have you tried switching to software rendering instead of hardware? You can do that by either setting an IDL preference or using renderer=1 when calling volume().
-Chris
|
|
|
Re: memory leak in volume() [message #92204 is a reply to message #92200] |
Wed, 28 October 2015 17:03   |
dg86
Messages: 118 Registered: September 2012
|
Senior Member |
|
|
On Wednesday, October 28, 2015 at 5:19:50 PM UTC-4, Chris Torrence wrote:
> On Tuesday, October 27, 2015 at 5:58:12 PM UTC-6, David Grier wrote:
>> Dear Folks,
>>
>> The Volume() function appears to leak memory in IDL 8.5, leading to frequent
>> crashes under both Mac and GNU/linux (Mac: Yosemite 10.10.5, XQuartz 2.7.8;
>> Ubuntu 15.04 and 15.10). Running from the command line, a few calls to Volume() will
>> cause IDL to quit to the UNIX prompt with a Bus error: 10, which is indicative of a memory leak.
>> Crashes are more frequent with large data sets.
>>
>> Once IDL has crashed this way the first time, restarting IDL and trying to create any function-graphics window will lead to another abrupt crash. The only way to fix this is to restart the X server, for instance by logging out and logging in again.
>>
>> This is too bad because volumetric rendering is still one of the things that IDL does
>> better than the competition, at least IMHO.
>>
>> TTFN,
>>
>> David
>
> Hi David,
> Have you tried switching to software rendering instead of hardware? You can do that by either setting an IDL preference or using renderer=1 when calling volume().
> -Chris
Dear Chris,
Setting renderer=1 did the trick. My most challenging volume renders repeatedly
without crashing, even from idlwave-mode in emacs 24.4, which has issues of its own.
Thanks very much indeed for putting my workflow back on track.
If these crashes were an issue with hardware acceleration, is there a plan to fix it?
Or is there a known underlying bug?
TTFN,
David
|
|
|
Re: memory leak in volume() [message #92266 is a reply to message #92204] |
Fri, 06 November 2015 10:00  |
chris_torrence@NOSPAM
Messages: 528 Registered: March 2007
|
Senior Member |
|
|
On Wednesday, October 28, 2015 at 6:03:13 PM UTC-6, David Grier wrote:
> On Wednesday, October 28, 2015 at 5:19:50 PM UTC-4, Chris Torrence wrote:
>> On Tuesday, October 27, 2015 at 5:58:12 PM UTC-6, David Grier wrote:
>>> Dear Folks,
>>>
>>> The Volume() function appears to leak memory in IDL 8.5, leading to frequent
>>> crashes under both Mac and GNU/linux (Mac: Yosemite 10.10.5, XQuartz 2.7.8;
>>> Ubuntu 15.04 and 15.10). Running from the command line, a few calls to Volume() will
>>> cause IDL to quit to the UNIX prompt with a Bus error: 10, which is indicative of a memory leak.
>>> Crashes are more frequent with large data sets.
>>>
>>> Once IDL has crashed this way the first time, restarting IDL and trying to create any function-graphics window will lead to another abrupt crash. The only way to fix this is to restart the X server, for instance by logging out and logging in again.
>>>
>>> This is too bad because volumetric rendering is still one of the things that IDL does
>>> better than the competition, at least IMHO.
>>>
>>> TTFN,
>>>
>>> David
>>
>> Hi David,
>> Have you tried switching to software rendering instead of hardware? You can do that by either setting an IDL preference or using renderer=1 when calling volume().
>> -Chris
>
> Dear Chris,
>
> Setting renderer=1 did the trick. My most challenging volume renders repeatedly
> without crashing, even from idlwave-mode in emacs 24.4, which has issues of its own.
> Thanks very much indeed for putting my workflow back on track.
>
> If these crashes were an issue with hardware acceleration, is there a plan to fix it?
> Or is there a known underlying bug?
>
> TTFN,
>
> David
Hi David,
We don't know the actual cause, but our hardware device drivers are probably old. It's a major undertaking to upgrade them, which is why it hasn't been fixed. I wouldn't hold your breath, but at least you have a reasonable workaround.
Cheers,
Chris
|
|
|