Technical support > Bugs in stable version (2.5)

Build of 2.5-dev fails to initialize com_genericPool before use on Darwin/Clang

<< < (2/4) > >>

Nokim:
I think we have different bugs in same subsystem. In my case it looks like miscalculated memory size to be allocated somewhere (like somebody thinks that sizeof(int) always equal to sizeof(uint32)), in your case it can be related to uninitialized variables (yes, valgrind reported such things too). Anyway, after commenting out overriding operators new and delete those errors vanished, so it's clear where to dig.

Jon_dArc:
Well, I'm stumped. I've confirmed that everything goes pear-shaped before anything in UFO:AI's main is run, so it's not a simple issue of reordering the initialization functions; digging around has failed to uncover any SDL-approved way of running anything before SDL's own initialization runs. The closest thing I could find to this sort of situation involved people giving the relevant memory pools static duration, which seems like it would be a pretty big change.

Looking at the commit that introduced the change, the commit message only discusses std::min and std::max-related changes—can anyone discuss the purpose of this change? I'm assuming that somehow the pools were used before it was made…

Secondarily, is there someone out there working on the Mac-specific parts who might be able to help figure out why other platforms don't seem to be having a problem?

~J

Mattn:
the std::min/std::max change was made by me as a little optimization. it now uses the inline versions of min/max, not the macros, thus, it only executes the statements that are given to the functions once.

Nokim:
My guess is that external libs start to use our operator new. And do so before pool get initialized. And this should be linker-related, not compiler.

In my case was usage in external libs of our delete operator after global freeing memory.

So I commented out those new and delete operator and have all running fine. They are supposed to speed up allocating memory and get some stat on it, but i prefer stability. And i'm using debug version which is slow anyway.

You can try to set breakpoint in operator new to find when it's first time called. And from where.

Jon_dArc:

--- Quote from: Mattn on June 22, 2012, 08:09:55 am ---the std::min/std::max change was made by me as a little optimization. it now uses the inline versions of min/max, not the macros, thus, it only executes the statements that are given to the functions once.

--- End quote ---
Sorry, what I meant was: the addition of the new/delete operator redefinitions occurs in a commit whose commit message only discusses std::min/std::max. I was asking for expansion on the operator redefinitions—the rest of the changes in the commit are indeed std::min/max related.


--- Quote from: Nokim on June 22, 2012, 09:09:16 am ---My guess is that external libs start to use our operator new. And do so before pool get initialized. And this should be linker-related, not compiler.
--- End quote ---
Yeah, that's what I concluded—though I'm not sure it's linker-related, as it does seem to be doing exactly what it was told. I'd been looking to see if there wasn't something that should be done to restrict the scope of the redefinition, or if SDL might not have some way to provide an initialization block that would run before SDL's internal initialization, but no dice.


--- Quote ---So I commented out those new and delete operator and have all running fine. They are supposed to speed up allocating memory and get some stat on it, but i prefer stability.
--- End quote ---
Are we sure the redefinitions are (ostensibly) purely an optimization?


--- Quote ---You can try to set breakpoint in operator new to find when it's first time called. And from where.
--- End quote ---
For about five minutes I was smacking myself on the forehead wondering why I didn't think of this, but I realized that it's because I already have the stack trace (posted above). In any event, since it happens strictly before anything in the UFO:AI entry point runs the details of precisely where it all goes wrong don't seem critical.

On the other hand, I think this makes for a satisfactory explanation of why the uninitialized pool only shows up on OS X (it just happens that on OS X SDL's initialization generates a call to new that doesn't appear on other platforms).

But other than simply removing the operators, I'm still no closer to identifying a solution.

~J

Navigation

[0] Message Index

[#] Next page

[*] Previous page