Log in

View Full Version : floating point data processing error. help request


vcmohan
20th June 2015, 13:13
I am getting an error when I am trying my plugin vcmod after some changes.
Unhandled exception at 0x5E3422BE (vapoursynth.dll) in VirtualDub.exe: Stack cookie instrumentation code detected a stack-based buffer overrun.
I remember to have successfully tested this plugin with the older official vapoursynth dll. I might have changed a few statements. Now I am trying with the latest dll. 32 bit.
Changes were in GetFrame method
in place of float * buf = new float[4096];
and at end of GetFrame delete[]buf;
Now I am using
float buf[4096]; with no delete.
Does this cause problems? I am trying this as creating a new buffer and deleting may be time consuming and possibly act as a synchronising point and multithread advantage is lost.

LoRd_MuldeR
20th June 2015, 17:51
I am getting an error when I am trying my plugin vcmod after some changes.
Unhandled exception at 0x5E3422BE (vapoursynth.dll) in VirtualDub.exe: Stack cookie instrumentation code detected a stack-based buffer overrun.
I remember to have successfully tested this plugin with the older official vapoursynth dll. I might have changed a few statements. Now I am trying with the latest dll. 32 bit.
Changes were in GetFrame method
in place of float * buf = new float[4096];
and at end of GetFrame delete[]buf;
Now I am using
float buf[4096]; with no delete.
Does this cause problems? I am trying this as creating a new buffer and deleting may be time consuming and possibly act as a synchronising point and multithread advantage is lost.

Well, if you do float buff[N] inside of a function body, it allocates that memory on the calling thread's stack, while float *buff = new float[N] allocates the memory on the heap (the local stack variable only stores the pointer to the heap memory). Indeed, this could be the reason for the stack overflow you are experiencing. Generally, it's not a very good idea to allocate large buffers on the stack. Especially not, when recursive calls are involved, where things will add up.

It's also not a good idea to frequently allocate+delete a lot of short-lived buffers on the heap, yes. But you could solve this by changing your design, so that each thread allocates all the required buffers once when the thread is created and does not delete them, until the thread itself is deleted. Of course this requires that you are keeping your thread running for a longer time (e.g. in some kind of "thread pool"), rather than creating+destroying a whole lot of short-lived threads.

Myrsloik
20th June 2015, 21:35
Allocate it on the heap. Really, just do it. The dangers of doing so are a bit exaggerated.

If you use vspipe to output the script it will even patch in tcmalloc in all loaded plugins which is made to handle that kind of allocation patterns very efficiently.

Do you get that error when allocating the float array on the stack or when it's on the heap? It sounds more like memory corruption caused by something else in your code.

cretindesalpes
21st June 2015, 00:01
Stack cookie instrumentation code detected a stack-based buffer overrun.
I think the error message looks quite clear: you are writing something out of your buffer. The error is detected because the stack-based checks were more thorough than heap-based ones in this situation. Check your indexes.

vcmohan
21st June 2015, 14:44
Yes. I checked indexes and wherever I thought they are at limit corrected them but I find strange happenings. The following script goes through OK.
img = core.imwri.Read([ "c:\images\stamil.jpg"])
#
ret = core.resize.Bicubic(img,height = 480, width = 720,format=vs.YUV420P8)

ret = core.fmtc.bitdepth(ret, flt = 1)
ret=core.std.Loop(ret,200)
ret = core.fmtc.bitdepth(ret,flt=0, bits = 8)
ret = core.resize.Bicubic(ret,format=vs.YUV444P8)
ret.set_output()
Above code runs well.
However if I change second line to read as
ret = core.resize.Bicubic(img,height = 480, width = 720,format=vs.YUV420P16)
I find strange happenings. For some reason conversion from 16 bit to float and back is creating problems.

It appears that the second fmtc need to be given bitdepth as 16 if originally it was 16 prior to conversion to float.

Since I got over indexing problems and isolated fmtc requirement, I will check different types of buffer allotments and report back.
thanks a lot.