CVS regression issue?

C++ coding using Panda3D
1

Hi,
Don’t know what has been changed, but using today a new Panda build from last CVS, I’m getting a really weird crash of an app that has been working fine upto yesterday night.

This is the call stack dump at the time of the crash.

What really strikes me is that this is reported happening while setting control_joints which is not related to orthographiclens… (and the reason why a call to find_child would end up dealing with texturestage and lenses…)

bool Pantin_Quid::set_control_joint(const int XN_J, const char *EGG_J, char *name) {
	CJ[XN_J]  = Actor.attach_new_node(name); // add new node "name" to be used to control EGG_J
	if (Bundle->control_joint(EGG_J, CJ[XN_J].node()) ) {// get EGG_J control through Control Joint "name"
		ChJ[XN_J] = DCAST(CharacterJoint, Bundle->find_child(EGG_J)); // ** HERE ** // ptr to EGG_J node in bundle tree
	} else {
		std::cout << "node: " << name << " not found in bundle tree \n";
		return false;
	}

At this point I’m really in the dark, since no changes were made to my code…

2

This smells like a build-sync issue. When you have calls to one function that end up somehow making calls to a completely unrelated function, it often means your build is out of sync: parts of your build are still compiled using an older version of Panda that maybe had different offsets in some of the low-level structures.

I’d make a full, clean rebuild just to prove that this isn’t what’s going on in this case.

David

3

Ok, I’m going to generate a full rebuild just in case.

4

Completed a full rebuild … and :

Don’t have a clue what is going on. Seems that while a Bundle->find_child(xx) is performed, some Null PT cleanup is taking place…

5

This is baffling to me as well. Are you using threads in your application? Can you prove it still happens with “support-threads 0”?

I don’t suppose a simple application fails in a similar way for you? Does pview work? All my applications are working just fine.

David

6

Hi,
pview just works fine.

with “support-threads 0”, it just gives another form of crash…

7

I’m still investigating what could be the root cause of this, since again no changes were made in my app code…

Having said so, let me take the opportunity to mention a second issue that popped up (again) after some recent cvs changes

This phenomenon started showing up say 2 weeks ago, then was healed by some CVS changes,
and reappeared for the last couple of days as a consequence of new CVS changes: on my side
I didn’t change anything on my code.

(1) USING OPENAL

load_prc_file_data(“”, “audio-library-name p3openal_audio”); // use openAL

mp3 playing fine (some subtle crackings heard)

** weird sounding: ie increased length duration, pitch and speed for ‘short’ sounds boing.wav and bell.wav.
ie a bell sound becomes similar to a buzzer… **

(2) USING FMOD

load_prc_file_data(“”, “audio-library-name p3fmod_audio”); // use fmod

no sound at all!

8

I sort of put my finger on a possible culprit.

For whatever reason _SECURE_SCL now defined as 0 is creating some troubles with additional modules included in my c++ app (at compile time this value is defined in dtoolconfig.h).

The compile ends up ok but at exec time this generates crashes…

Digging into past versions of makepanda.py, I noticed that the value used to be set at 1. I don’t know the reason it was changed, and the consequences, but apparently this has generated side effects.

What I’ll do is try a full rebuild with _SECURE_SCL at 1.

Honestly I’m far from having fully understood the underlying phenomenons… Let’s see…

9

I confirm that getting _SECURE_SCL at 1 in makepanda.py solved the issue. (although there may be some tricky problem well hidden somewhere).

Btw. for the second phenomenon reported (ie the one related to accelerated wav play) it still exists!

10

Wow, that’s a helluva thing. We ran into compilation problems on MSVS2010, which turned out to be related to the explicit setting of _SECURE_SCL to 1. We ourselves weren’t sure why it was set there in the first place (another developer did it, but he’s since dropped out of communication). We guessed it was maybe a “best practices” thing, because it seems to be related to enabling additional checking within the STL library.

We fixed our problem by changing the setting from 1 to 0. But it appears that explicitly setting it to 0 is causing you problems. Maybe the right answer is not to explicitly set it to either value. I’ll remove this from makepanda and we’ll see what happens.

Edit: can you post your sound files so I can test the weird audio issues on my build?

David

11

Hi,
Here are the 2 sound files
rapidshare.com/files/2414930192/bell.wav
rapidshare.com/files/3453952356/boing.wav

I don’t think the issue is related to these specific files, since they’ve been playing ok for a long time.
What has happen since then is that depending on the cvs versions (some worked ok), these files started to sound in an accelerated way (ie the boing became a whizzzzzz, and the bell a buzzer…) this under openAL, with the sound.play() being called inside a secondary threaded task_chain… (The phenomenon is the same if I switch to set option no thread)

Moreover as previously mentionned I did try to check if using fmod would change something: the net result is no sound at all…

12

Well, I was able to reproduce your problems playing these files on my own computer–even though I’m running on a Mac. I don’t have an FMod build here, but they sounded strange via OpenAL. It didn’t have anything to do with threading; the same thing happens when they are played in the main thread.

On investigation, it appears that these .wav files are 8-bit PCM, which relies on a slightly more obscure variation on the .wav standard (original .wav files were all 16-bit PCM). When I re-encode them to 16-bit PCM, they play just fine via OpenAL.

We did recently upgrade the ffmpeg library used in the build; perhaps the new version is for some reason a little less robust with the .wav file format than the old version, and now it only understands 16-bit PCM?

Edit: addendum. I got my local FMod build working, and I find that it can play both 8-bit and 16-bit versions successfully on my Mac. But perhaps there is a different problem with the Windows FMod build.

David

13

Excellent that clarifies the matter!

wrt. fmod, the sound issue is not solely tied to these 2 files, actually I’m getting no sound at all (with the other files that are mp3)!

14

Hmm, are you sure fmod is loading at all? Are you getting any error messages about fmod when starting?

David

15

Well, as far as I can see in vs2008 output pane when launching it in debug mode libp3fmod_audio.dll is loaded and I’m getting no warning or whatsoever in the panda console…

I’m not using FMOD in my app, so this doesn’t really hurt, but just to mention…

16

FWIW, I just had to look into this, and the key issue is for the _SECURE_SCL to match in all modules that pass STL data structures to eachother (including std::string), since _SECURE_SCL changes the in-memory layout.

In VS2008, both debug and release default to _SECURE_SCL being on (which has a serious performance impact on using STL iterators). In VS2010, they changed it to default to off in release builds.

So, panda3d should be able to set it to on or off in any version of VS, but the important thing is to be clear about what value was used to compile it, so C++ consumers can use the same setting. (And it can’t just be set in the Panda3D headers, since STL may be included first).

A good discussion of this is at :
connect.microsoft.com/VisualStu … re-scl-0-c
Key quote is “Mismatch will be not detected by the VC8/VC9 linker, and will cause incomprehensible crashes”.

I realize this post is old, but hope this helps others,
Sam