video sequencer crashes when moving around within a sequence.
Closed, ResolvedPublic

Description

I have been working with 2.5 for quite some time on a .blend file which contained multiple videos from my iphone 3gs. The sequence was nothing special. Simple crop and offset properties set. The strips were setup to replace over, and allowed you to view multiple videos simultaneously.

After upgrading to 2.6. Opening the .blend file opens fine, the first frame is painted and often even a few advances of the frame offset work fine. However, it ends up crashing.

Unhandled exception at 0x77cd15de in blender.exe: 0xC0000005: Access violation reading location 0x0b0cb410.

I tried both the x64 and x86. I tried builds from buildbot. I tried to find a simple binary debug build somewhere, but couldn't find a usable one.
Ended up using SVN, cmake, and VS2010.

I found that:
[21:14] <MrJonJacob> I figured out what was causing my issue. the float position on AUD_AnimateableProperty::read(float position, float* out), is coming in negative.
[21:14] <MrJonJacob> not sure why, but if I test for <0 and multi by -1 all the unexpected access errors stop.
[21:28] <MrJonJacob> I just have about 10-15 movies in the sequencer nothing special. when I upgraded from 2.5 -> 2.6 it started crashing when I moved around in the sequence editor
[21:29] <MrJonJacob> I don't think it is ever valid for that to be negative
[21:29] <MrJonJacob> and if it is, it crashes.
[21:34] <MrJonJacob> my modified build seems to be working fine though! :)

I can try and create a sample file if someone else has trouble recreating this issue.

Thanks for Blender guys!

--dave
http://dave.thehorners.com/

Details

Type
Patch

> blender.exe!AUD_AnimateableProperty::read(float position=-27624.398, float * out=0x000000000026e4b8) Line 143 + 0x14 bytes C++
blender.exe!AUD_SequencerReader::read(int & length=2048, bool & eos=false, float * buffer=0x000000000aa1b2e0) Line 184 C++
blender.exe!AUD_ConverterReader::read(int & length=2048, bool & eos=false, float * buffer=0x000000000aa37c50) Line 76 C++
blender.exe!AUD_OpenALDevice::AUD_OpenALHandle::seek(float position=77275.047) Line 259 C++
blender.exe!AUD_seek(AUD_Reference<AUD_IHandle> * handle=0x000000000abbb020, float seekTo=77275.047) Line 488 + 0x25 bytes C++
blender.exe!sound_play_scene(Scene * scene=0x000000000ab37c38) Line 569 C
blender.exe!ED_screen_animation_play(bContext * C=0x0000000003dc2208, int sync=-1, int mode=1) Line 3046 C
blender.exe!screen_animation_play_exec(bContext * C=0x0000000003dc2208, wmOperator * op=0x000000000428b9b8) Line 3068 C
blender.exe!wm_operator_invoke(bContext * C=0x0000000003dc2208, wmOperatorType * ot=0x000000000409cdc8, wmEvent * event=0x00000000042012a8, PointerRNA * properties=0x000000000026f068, ReportList * reports=0x0000000000000000, short poll_only=0) Line 818 + 0x19 bytes C
blender.exe!wm_operator_call_internal(bContext * C=0x0000000003dc2208, wmOperatorType * ot=0x000000000409cdc8, PointerRNA * properties=0x000000000026f068, ReportList * reports=0x0000000000000000, short context=1, short poll_only=0) Line 975 + 0x3c bytes C
blender.exe!WM_operator_name_call(bContext * C=0x0000000003dc2208, const unsigned char * opstring=0x0000000141e33670, int context=1, PointerRNA * properties=0x000000000026f068) Line 1024 + 0x28 bytes C
blender.exe!ui_apply_but_funcs_after(bContext * C=0x0000000003dc2208) Line 393 C
blender.exe!ui_handler_region_menu(bContext * C=0x0000000003dc2208, wmEvent * event=0x000000000a9c3d28, void * UNUSED_userdata=0x000000000aba6c78) Line 6457 C
blender.exe!wm_handler_ui_call(bContext * C=0x0000000003dc2208, wmEventHandler * handler=0x000000000430e738, wmEvent * event=0x000000000a9c3d28, int always_pass=0) Line 352 + 0x1b bytes C
blender.exe!wm_handlers_do(bContext * C=0x0000000003dc2208, wmEvent * event=0x000000000a9c3d28, ListBase * handlers=0x000000000a643f28) Line 1642 + 0x1f bytes C
blender.exe!wm_event_do_handlers(bContext * C=0x0000000003dc2208) Line 1944 + 0x20 bytes C
blender.exe!WM_main(bContext * C=0x0000000003dc2208) Line 369 C
blender.exe!main(int argc=1, const unsigned char * * argv=0x0000000003d735d0) Line 1278 C
blender.exe!__tmainCRTStartup() Line 278 + 0x19 bytes C
blender.exe!mainCRTStartup() Line 189 C
kernel32.dll!00000000774a652d()
[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]
ntdll.dll!0000000077a3c521()


in
blender.exe!AUD_SequencerReader::read(int & length=2048, bool & eos=false, float * buffer=0x000000000aa1b2e0) Line 184 C++
m_factory->m_orientation.read(frame, q.get());
frame = -27624.398

Could you please provide a test file where this happens, because it seems to be a bug further up in the class hierarchy, as the AnimatableProperty should never get a negative value as input.

I've not tried to send or package up a blend and its videos before.... I tried moving the .blend file without the videos to another drive, it does seem to crash too. Though it doesn't happen when I poke around the sequencer, more when I actually run the animation (alt-a). So hopefully it happens on your machine without the media. Otherwise, I would really like to help debug and kill the issue if possible.

Let me know if I can provide any details further up the call stack to help illuminate the issue.

AUD_SequencerReader::read
+ it {m_reference=0xcdcdcdcdcdcdcdcd m_original=0xcdcdcdcdcdcdcdcd } std::_List_iterator<std::_List_val<AUD_Reference<AUD_SequencerHandle>,std::allocator<AUD_Reference<AUD_SequencerHandle> > > >
+ this 0x0000000003ada8e0 {m_position=-2147483648 m_device={...} m_factory={...} ...} AUD_SequencerReader * const
length 2048 int &
eos false bool &
+ buffer 0x000000000b7f5f00 float *
pos 0 int
frame -24347.885 float
cfra -24348 int
+ specs {rate=44100.000000000000 channels=AUD_CHANNELS_STEREO } AUD_Specs
volume 1.0000000 float
len 2048 int
+ q {m_v=0x00000000002fee38 m_w=1.0000000 m_x=0.00000000 ...} AUD_Quaternion
+ v2 {m_v=0x00000000002fee08 m_x=0.00000000 m_y=0.00000000 ...} AUD_Vector3
time -48695.773 float
+ v {m_v=0x00000000002fedd8 m_x=0.00000000 m_y=0.00000000 ...} AUD_Vector3


May the break be with you.

Thanks,
--dave
http://dave.thehorners.com/

Ok, well I couldn't get the attachment thing to work on here for some reason. It would either tell me I had a missing parameter? or it would tell me that I had a double submission. anyways, life is too short.

http://dl.dropbox.com/u/5668823/DDD.blend

Good luck,
--dave

No without the audio files I don't get a crash as it doesn't start playing anything if there's no file ;)

But looking at the above value of cfra: -24348 that's impossible negative frame numbers shouldn't occur!

That doesn't make sense to me, as it crashes locally on the other drive without the data. But trying to reproduce is always tricky...and more work. :)

Interesting that you can't get it to crash, as it did crash without the video files in proper locations for me....though I understand the reasoning.
you might try placing some video files named properly in the locations it is referencing to see if this breaks it.

I'd rather not distribute my videos. Which means burden of proof in trying to recreate. Can you suggest on further information or thoughts on where this negative value might come into play here? I would be willing to provide remote access of some sort if need be. Though, I can also try and ferret out the root cause with a bit of guidance maybe.

Thanks,
--dave

more random locals....

We are seeking positive.
int AUD_seek(AUD_Handle* handle, float seekTo)
+ handle 0x0000000003b37290 {m_reference=0x000000000ba0e2d0 m_original=0x000000000ba0e2d0 } AUD_Reference<AUD_IHandle> *
seekTo 85368.008 float

positive position..
bool AUD_OpenALDevice::AUD_OpenALHandle::seek(float position)
i 0 int
+ this 0x000000000ba0e2d0 {m_isBuffered=false m_reader={...} m_keep=true ...} AUD_OpenALDevice::AUD_OpenALHandle * const
length 2048 int
err 0 int
info 4113 int
+ specs {format=AUD_FORMAT_S16 rate=44100.000000000000 channels=AUD_CHANNELS_STEREO ...} AUD_DeviceSpecs
position 85368.008 float

Well your file is really strange with 1/2 fps... the cursor works kind of weird here when I play back.

Anyway, if you want to find the bug you have to find out where the value is set to a negative value.

Step through AUD_OpenALDevice::AUD_OpenALHandle::seek and especially into the m_reader->seek((int)(position * m_reader->getSpecs().rate)); call.

Check where m_position of the AUD_SequencerReader gets the value -2147483648. I guess that happens in AUD_SequencerReader::seek, so you might add an if there to check if the value is negative and set a breakpoint there to find out.

Good luck

Thanks, you are right, the fps is the issue here...

So in AUD_SequencerReader.cpp, 164
while(pos < length)
{
frame = time * m_factory->m_fps;
cfra = int(floor(frame));

I put a break point in here to see when cfra became negative.
m_factory->m_fps=0.49999994
m_position=2048
frame 0.023219952 float
cfra -858993460 int
time 0.092879817 float

thoughts?

Thanks again.
--dave

also, putting a conditional break for the first time cfra goes <0, I found another frame value that goes crazy negative....

frame=0.0
cfra -858993460 int

So your computer really calculates int(floor(frame)) to a negative value even if frame is positive?! o_O

This is kind of impossible, are you sure you checked cfra after that line and not before, when there's garbage stored in that variable as it's not initialised?

The more important question is, how does m_position get negative? Because cfra depends on frame, frame on time and time on m_position.

m_position could only get negative if the length of the read call is negative or if the position in seek is negative and that should both be impossible too.

I know, strange. Maybe you are right, maybe I was reading the uninitialized value yesterday. Sorry. (I will verify this later)

Ok, so I set a conditional breakpoint in AUD_SequencerReader::seek(int position) for when position<0.
And whadda know, the first negative value was -2147483648.

> blender.exe!AUD_SequencerReader::seek(int position=-2147483648) Line 52 C++
blender.exe!AUD_EffectReader::seek(int position=-2147483648) Line 49 C++
blender.exe!AUD_OpenALDevice::AUD_OpenALHandle::seek(float position=75279.578) Line 232 C++
blender.exe!AUD_seek(AUD_Reference<AUD_IHandle> * handle=0x0000000003b6ffc0, float seekTo=75279.578) Line 488 + 0x25 bytes C++
blender.exe!sound_seek_scene(Main * bmain=0x000000000a652a08, Scene * scene=0x000000000a69e0f8) Line 628 C

looks like in:
bool AUD_OpenALDevice::AUD_OpenALHandle::seek(float position)
at:
m_reader->seek((int)(position * m_reader->getSpecs().rate));
we go negative.

But I don't really understand this either. Since stepping into all the references to find the rate, yielded me a rate of 44100?! positive?
‡ AUD_EffectReader::getSpecs returned {rate=44100.000000000000 channels=AUD_CHANNELS_STEREO } AUD_Specs
+ m_reader {m_reference=0x000000000a6332f0 m_original=0x000000000a6332f0 } AUD_Reference<AUD_IReader>
position 78717.000 float
+ this 0x000000000a77bf50 {m_isBuffered=false m_reader={...} m_keep=true ...} AUD_OpenALDevice::AUD_OpenALHandle * const
step again then into the seek:
+ m_reader {m_reference=0x000000000a77ab00 m_original=0x000000000a77ab00 } AUD_Reference<AUD_IReader>
position -2147483648 int
+ this 0x000000000a6332f0 {m_buffer={...} m_format=AUD_FORMAT_S16 m_convert=0x00000001409b24e0 } AUD_EffectReader * const

maybe AUD_SequencerReader::seek(int position) should be checking for negative values?
any thoughts on why 78717.000 *44100.000000000000 is negative?

I never had any of these problems on my grandfathers slide rule!

Later,
--dave

We're on the right track!

78717.0 *44100.0 is not negative obviously, but a pretty high value; one that doesn't fit into an int anymore and the position is an int, so it's not suprising that the conversion from float to int results in that value as it's too big for an int.

So the question is where the value 78717.0 comes from? If you check the function sound_seek_scene where the AUD_seek call happens, the value is calculated as CFRA / FPS.

As your FPS = 0.5, the CFRA (= current frame) is 78717 * 2 = 157434, so you seeked to that frame number to let it crash, right?! The maximum frame you would be allowed to seek to is 97391 ( (2^31 - 1) / 44100 * 2 ) and above it should crash. But your file has 47552 as end frame which is less than half of that maximum, so did you really seek that far or did the value 78717.0 origin in another bug?

Regards

Ahh wait, my calculation is wrong, it's not * 2 it's * 0.5

So 78717 * 0.5 = 39358,5 that's a frame within your animation and yes I now get that negative value too there.

So the problem is really your big length and low FPS value of the animation, why do you use 0.5 FPS anyway?!

I don't really see a solution to really fix the problem. The only thing I can do is not letting it work outside the limits of an integer, that would mean for your animation that sound doesn't work correctly starting with frame (2^31-1) / 44100 * 0.5 = 24348.

I dunno, if you ask me, it shouldn't crash. The function that is making references into memory using pointer math, should be protected. Funny too as none of the movies were imported with any audio! The audio subsystem is crashing, but there isn't anything to be played.

I do agree the FPS is a bit strange. But it is a valid value when using the mouse... Changing the FPS to fractional plays all the tracks really really slow. You can also use track effects to slow each track independently. But adjusting the global FPS would have an effect on all of them.

I didn't realize that I was playing with fire when adjusting a fractional FPS on long videos.

Second, I am using an x64 machine with x64 debug active in visual studio. Shouldn't that alleviate some of the overflow? Shouldn't that math be 2^64-1?

Thanks,
--dave


It shouldn't crash obviously yes, that's not the point and fixed in seconds, I actually fixed that right now in revision 45055.

But it's a fact that it's not possible to have sequences longer than 27 hours at an audio rate of 44100 using integers in the engine (FPS don't matter considering the duration in seconds, FPS just matter if you calculate in frames, as duration = frames / FPS). If you're on a 32 or 64 bit machine doesn't change anything there, the datatype remains 32 bit.

Anyway, the crashing bug is fixed in svn now, so I'm closing this. Thanks for the help!

Great, protecting m_position is the right thing to do. Thank you!

I dunno, there are still issues with fractional FPS. It has crashed on me a few times. One time in the same place in the Prop::read()... the position wasn't negative but the reference was still bad.

I also just got this: I created a new blender scene, dropped a moderately large video in there, set a fractional FPS .5 .4..etc. and move around. it crashes.

This last one was also strange!
Unhandled exception at 0x0000000140dca26a in blender.exe: 0xC0000005: Access violation reading location 0xffffffffffffffff.

> blender.exe!AUD_SoftwareDevice::AUD_SoftwareHandle::update() Line 72 + 0x8 bytes C++
blender.exe!AUD_SoftwareDevice::mix(unsigned char * buffer=0x000000000e76f748, int length=1) Line 723 C++
blender.exe!AUD_ReadDevice::read(unsigned char * buffer=0x000000000e76f748, int length=1) Line 61 C++
blender.exe!AUD_SequencerReader::read(int & length=2048, bool & eos=false, float * buffer=0x000000000e76c620) Line 196 C++
blender.exe!AUD_ConverterReader::read(int & length=2048, bool & eos=false, float * buffer=0x000000000e76a5a0) Line 76 C++
blender.exe!AUD_OpenALDevice::updateStreams() Line 848 C++
blender.exe!AUD_openalRunThread(void * device=0x000000000b78e820) Line 774 C++

That line is

if(m_relative)
SL = -m_location;

Really deref'ing a local? m_relative is no good?!

here are my locals in the crash if that helps:
+ this 0xfeeefeeefeeefeee {m_reader={...} m_pitch={...} m_resampler={...} ...} AUD_SoftwareDevice::AUD_SoftwareHandle * const
+ A {m_v=0x0000000017b9f058 m_x=-1.0737418e+008 m_y=-1.0737418e+008 ...} AUD_Vector3
+ SL {m_v=0x0000000017b9ef48 m_x=0.00000000 m_y=0.00000000 ...} AUD_Vector3
+ N {m_v=0x0000000017b9f028 m_x=-1.0737418e+008 m_y=-1.0737418e+008 ...} AUD_Vector3
distance -1.0737418e+008 float
Asquare -1.0737418e+008 float
flags 0 int
+ Z {m_v=0x0000000017b9eff8 m_x=-1.0737418e+008 m_y=-1.0737418e+008 ...} AUD_Vector3
+ orientation {m_v=0x0000000017b9efc8 m_w=-1.0737418e+008 m_x=-1.0737418e+008 ...} AUD_Quaternion


I dunno if you'd rather I create a new ticket or open this one again?

As you can see here:

+ this 0xfeeefeeefeeefeee {m_reader={...} m_pitch={...} m_resampler={...} ...} AUD_SoftwareDevice::AUD_SoftwareHandle * const

this->m_relative results in an access violation as the this pointer has an invalid value!

As I cannot reproduce the bug, you'll have to find out, where that value comes from!

This apparently is not related to the fractional FPS and it is a bug in the VSE somewhere.

I created a new .blend, which I can provide if you would like to try and reproduce, though I don't think there is anything special about this blend or data.

I went to:
http://www.youtube.com/watch?v=fqymcJRSbxI
and used the YouTube Downloader chrome plugin to get an mp4 file for use in testing.

I went to the video sequencer and imported the movie on frame 0, started to do some hard cuts (K), with some grab translations (G). Moving around and playing with the view of the sequencer somehow caused the same bad this pointer on m_relative lookup. :( (Though, nice to know that it happens without changing the fractional FPS).

> blender.exe!AUD_SoftwareDevice::AUD_SoftwareHandle::update() Line 72 + 0x8 bytes C++
blender.exe!AUD_SoftwareDevice::mix(unsigned char * buffer=0x000000000a4652b0, int length=1) Line 723 C++
blender.exe!AUD_ReadDevice::read(unsigned char * buffer=0x000000000a4652b0, int length=1) Line 61 C++
blender.exe!AUD_SequencerReader::read(int & length=2048, bool & eos=false, float * buffer=0x000000000a461330) Line 196 C++
blender.exe!AUD_ConverterReader::read(int & length=2048, bool & eos=false, float * buffer=0x000000000a3495a0) Line 76 C++
blender.exe!AUD_OpenALDevice::updateStreams() Line 848 C++
blender.exe!AUD_openalRunThread(void * device=0x0000000003a865d0) Line 774 C++
pthreadVC2.dll!0000000000c44d75()
[Frames below may be incorrect and/or missing, no symbols loaded for pthreadVC2.dll]
pthreadVC2.dll!0000000000c47fdb()
pthreadVC2.dll!0000000000c4808f()
kernel32.dll!0000000076c1652d()
ntdll.dll!000000007705c521()

+ this 0xcdcdcdcdcdcdcdcd {m_reader={...} m_pitch={...} m_resampler={...} ...} AUD_SoftwareDevice::AUD_SoftwareHandle * const
+ A {m_v=0x0000000013edeac8 m_x=-1.0737418e+008 m_y=-1.0737418e+008 ...} AUD_Vector3
+ SL {m_v=0x0000000013ede9b8 m_x=0.00000000 m_y=0.00000000 ...} AUD_Vector3
+ N {m_v=0x0000000013edea98 m_x=-1.0737418e+008 m_y=-1.0737418e+008 ...} AUD_Vector3
distance -1.0737418e+008 float
Asquare -1.0737418e+008 float
flags 0 int
+ Z {m_v=0x0000000013edea68 m_x=-1.0737418e+008 m_y=-1.0737418e+008 ...} AUD_Vector3
+ orientation {m_v=0x0000000013edea38 m_w=-1.0737418e+008 m_x=-1.0737418e+008 ...} AUD_Quaternion

Do you have a suggestion on how to go about finding the offending code which is killing our this? I'm not sure how to go about break point debugging my way to find this issue...since I still am tinkering with the interface in unknown ways to cause this issue.. maybe you would like the blend and movie file zipped up for your investigation?

Can we please open this ticket again or create another? Or do we continue working under a closed ticket?

Thanks.
--dave

within void AUD_SoftwareDevice::mix(data_t* buffer, int length), the bad values are coming from the m_playingSounds iterator..
std::list<AUD_Reference<AUD_SoftwareHandle> > m_playingSounds;
--
// for all sounds
AUD_HandleIterator it = m_playingSounds.begin();
while(it != m_playingSounds.end())
{
sound = *it;

are these values like dead pointers? cdcdcd and feeefeee. I've not spent much time with the reference counting AUD_ReferenceHandler myself, maybe we are deleting the object somewhere?

any thoughts?

Thank you!
--dave

Seems to occur very easily if you import a movie with sound, press play, and then while the movie is playing, click and drag within the video sequence editor, forward and backward quickly (while holding down on the left button), while the movie is still playing. It will jump around and play, then crash. Or, I have also had strange effects happen, like the sound will become whiny noise, which will continue after you release your mouse, or pause/stop and play!

multi-threaded fun.

Also, I am interested in knowing why when you import a movie, the audio and video track don't have the same length. (even before cutting or manipulating it in any way)
Shouldn't a default new .blend file, with import movie with audio, result in two strips (1 audio & 1 video) equal length?

Thanks again,
--dave

Hey!

Sorry for the late reply, been pretty busy. I can understand that there's a problem here. Again M$ has a crappy implementation of the STL so that bug only appears on windows. I have to figure out a way to do what I'm currently doing differently. That might take some time, as I have to concentrate on other things first. But before I do so, you don't have to investigate further here.

About the equal length: the audio and video lengths are meassured differently, that causes the difference, it's a library thing, so nothing we can change really, sorry.

Regards

Hello there,

So, which OS distribution are you using? I guess I'm going to need to switch platforms, because the VSE in windows is pretty much unusable in current state. I was considering looking at the video texture stuff in the game engine....which I haven't looked at yet, wondering if this would exhibit the same sort of behaviors.

I am taking a stab at saying that we are removing the object in one thread while iterating in another. I tried adding mutexs for the paused and playing std:lists within AUD_SoftwareDevice & AUD_OpenALDevice. locking and unlocking around the removes and iteration loops....hoping that such a thing would help. Nope. Now it just crashes with corruption in such a way that I can't get a proper callstack to make heads or tails. I don't know if that helps or not, but if you are interested I can send a patch.

I'd like to help if possible, but I also understand if you are very busy and want to make these changes yourself.

*from SGI STL Thread-safety website - Client must lock shared mutable containers.
http://www.sgi.com/tech/stl/thread_safety.html

Also, there has been recent attempts at improvement in the MS stack when it comes to concurrency http://msdn.microsoft.com/en-us/library/dd504906.aspx
Don't know if that applies or is interests you at all since it is so M$ specific.


Have a nice day.
--dave
http://dave.thehorners.com/tech-talk/random-tech/375-blender

I do notice that most times that the crashes occur, we are often looking at a this value of 0xcdcdcdcd... which apparently is a special fill value in the debug runtime. New objects which are allocated, but not yet initialized. http://msdn.microsoft.com/en-us/library/bebs9zyz.aspx

I did uncomment MEM_DEBUG and running, when I do that, I got the following (with a random crash), which may or may not shed more light?:

> blender.exe!AUD_Reference<AUD_SoftwareDevice::AUD_SoftwareHandle>::operator=(const AUD_Reference<AUD_SoftwareDevice::AUD_SoftwareHandle> & ref={...}) Line 183 + 0xa bytes C++
blender.exe!AUD_SoftwareDevice::mix(unsigned char * buffer=0x0000000004310040, int length=1) Line 733 C++
blender.exe!AUD_ReadDevice::read(unsigned char * buffer=0x0000000004310040, int length=1) Line 61 C++
blender.exe!AUD_SequencerReader::read(int & length=2048, bool & eos=false, float * buffer=0x000000000430f840) Line 196 C++
blender.exe!AUD_ConverterReader::read(int & length=2048, bool & eos=false, float * buffer=0x000000000caf2da0) Line 76 C++
blender.exe!AUD_OpenALDevice::updateStreams() Line 862 C++
blender.exe!AUD_openalRunThread(void * device=0x000000000423e760) Line 787 C++
pthreadVC2.dll!0000000000554d75()
[Frames below may be incorrect and/or missing, no symbols loaded for pthreadVC2.dll]
pthreadVC2.dll!0000000000557fdb()
pthreadVC2.dll!000000000055808f()
kernel32.dll!BaseThreadInitThunk() + 0xd bytes
ntdll.dll!RtlUserThreadStart() + 0x21 bytes

on line:
m_original = ref.m_original;
locals:
pos 0 int
stopSounds [0]() std::list<AUD_Reference<AUD_SoftwareDevice::AUD_SoftwareHandle>,std::allocator<AUD_Reference<AUD_SoftwareDevice::AUD_SoftwareHandle> > >
+ buf 0x000000000cb60520 float *
eos false bool
+ sound {m_reference=0x00000000042db690 m_original=0x00000000042db690 } AUD_Reference<AUD_SoftwareDevice::AUD_SoftwareHandle>
len 1 int
pauseSounds [0]() std::list<AUD_Reference<AUD_SoftwareDevice::AUD_SoftwareHandle>,std::allocator<AUD_Reference<AUD_SoftwareDevice::AUD_SoftwareHandle> > >
+ it {m_reference=??? m_original=??? } std::_List_iterator<std::_List_val<AUD_Reference<AUD_SoftwareDevice::AUD_SoftwareHandle>,std::allocator<AUD_Reference<AUD_SoftwareDevice::AUD_SoftwareHandle> > > >
+ this 0x00000000041cea40 {m_playing=true } AUD_SoftwareDevice * const
+ buffer 0x0000000004310040 unsigned char *
length 1 int


so the iterator is jacked:
+ it {m_reference=??? m_original=??? }
and the m_playingSounds std::list is full of allocated but uninitialized data....

- m_playingSounds [2](...) std::list<AUD_Reference<AUD_SoftwareDevice::AUD_SoftwareHandle>,std::allocator<AUD_Reference<AUD_SoftwareDevice::AUD_SoftwareHandle> > >
- [0] {m_reference=0xcdcdcdcdcdcdcdcd m_original=0xcdcdcdcdcdcdcdcd } AUD_Reference<AUD_SoftwareDevice::AUD_SoftwareHandle>
+ m_reference 0xcdcdcdcdcdcdcdcd {m_reader={...} m_pitch={...} m_resampler={...} ...} AUD_SoftwareDevice::AUD_SoftwareHandle *
m_original 0xcdcdcdcdcdcdcdcd void *
(error) 0 int

lately I've been toying with Application Verifier and gxflags (global flags) out of the windows sdk. supposedly good at finding heap corruption...

as for the equal length thing, you can meta strip them and cut them. But ultimately, I don't know how to keep the audio in sync, on import, the video and audio don't line up, and best I can come up with so far is to cut and try and align the cut with each cut. nothing better currently I guess?

I am still quite interested in hearing which distro you are using and a little on your thoughts about where this issue originates and plans/thoughts on possible solutions.

have a nice night, and thanks Joerg .
--dave

Hello there, I am not trying to pester. But I do think this should be an open bug. I haven't thought or done anything more with this since last post. Just wanted to keep the conversation going about this issue within blender VSE. I would enjoy helping with the fix. I understand your time is limited.

Thank you Joerg.
--dave

Hi!

Can you try if the problem still persists in a build of revision 46036 or later?
If so, feel free to open a new bug report and assign it to me.

Regards

Joerg Mueller (nexyon) closed this task as "Resolved".Apr 28 2012, 10:43 PM