Annoying problem with free() (newlib) [spreading quickly...]

I'm now banging my head against this one very annoying crash from cmake...

Here is the upper part of the stack trace:

**************************
Stack trace:
native kernel module newlib.library.kmod+0x000107cc
native kernel module newlib.library.kmod+0x0000632c
cmake:_ZdlPv()+0x18 (section 1 @ 0x3caea0)
cmake:_ZNSs4_Rep10_M_destroyERKSaIcE()+0x10 (section 1 @ 0x3c4360)
cmake:_ZNSsD1Ev()+0x50 (section 1 @ 0x3c520c)
cmake:_ZSt8_DestroyISsEvPT_()+0x20 (section 1 @ 0x29028)
cmake:_ZSt13__destroy_auxIPSsEvT_S1_St12__false_type()+0x28 (section 1 @ 0x29068)
cmake:_ZSt8_DestroyIPSsEvT_S1_()+0x30 (section 1 @ 0x290cc)
cmake:_ZSt8_DestroyIPSsSsEvT_S1_SaIT0_E()+0x2C (section 1 @ 0x29110)
cmake:_ZNSt6vectorISsSaISsEED1Ev()+0x148 (section 1 @ 0x314f0)
cmake:_ZN9cmCommand17InvokeInitialPassERKSt6vectorI18cmListFileArgumentSaIS1_EER17cmExecutionStatus()+0x260 (section 1 @ 0x28b96c)
cmake:_ZN10cmMakefile14ExecuteCommandERK18cmListFileFunctionR17cmExecutionStatus()+0x550 (section 1 @ 0xb3c5c)
(etc...)
*****************************

Here is the code from cmake/Source/cmCommand.h:
*****************************
virtual bool InvokeInitialPass(const std::vector<cmListFileArgument>& args,
cmExecutionStatus &status)
{
std::vector<std::string> expandedArguments;
if(!this->Makefile->ExpandArguments(args, expandedArguments))
{
// There was an error expanding arguments. It was already
// reported, so we can skip this command without error.
return true;
}
return this->InitialPass(expandedArguments,status);
}
*****************************

(I believe, that the error happens after the last return, in some destructor function, I have tried inserting those annoying printf() statements...)

...aand here is the output from "nm libstdc++.a" that I believe has to do with the crash:

*****************************
del_op.o:
00000000 T _ZdlPv
U __gxx_personality_sj0
U free
*****************************

So, I'm guessing, that whatever _ZdlPv() is doing, it must be calling free(), which in turn then fails for some reason. I have searched the adtools directory on my computer for a del_op.#? file, but can't seem to find it.

Anyone, please give me a push!

I have in the meantime found the code in libstdc++ that is refered (I think):

********************* del_op.cc ****************
#include <bits/c++config.h>
#include "new"
#if _GLIBCXX_HOSTED
#include <cstdlib>
#endif

#if _GLIBCXX_HOSTED
using std::free;
#else
// A freestanding C runtime may not provide "free" -- but there is no
// other reasonable way to implement "operator delete".
extern "C" void free(void *);
#endif

_GLIBCXX_WEAK_DEFINITION void
operator delete (void *ptr) throw ()
{
if (ptr)
free (ptr);
}
**************************************************
It doesn't help me much though... What does "throw" mean??
And what is the scope of the "delete operator"??

If this is really a bug in libstdc++, then there is not much
hope I can fix it. I was hoping of some a little more knowledgable person
to give some enlightened words on what to do about it... ;-(

@alfkil
Dunno if it will helps, but imho you will be out of luck here with such questions, and you need directly write mails to brothers (Thomas works on it if i remember right) and to SBA. They for sure should know what is that and how to fix it

Quote:
That is a lot of stuff to put on the stack so check that first.

Quote:
When you see throw() it means the function does not throw exceptions. This is being phased out and will be replaced by noexcept(true) in the next C++ standard.

Quote:
The scope is global.

Keep in mind that exceptions do not work properly in C++ if you are using newlib.library. This is a known problem which Hans-Joerg was going to look into. There is a thread about it on the support forum someplace.

@ssolie

Quote:

The problem is only when using the shared libstdc++. If it's statically linked everything works fine.

Link to thread

i've posted this a lot of times.. actually the only solution is to delete all libstdc++.so from your SDK... waiting for the fix.

@afxgroup

Do you by any chance have a smaller case example of how the bug works?? I think that would be very helpful for reporting it. In my case, it only happens under certain circumstances in a very complex setting (in the middle of a long script with subscripts, calling external processes etc etc...).

EDIT: and by the way, I am using 10 MB of stack space.

Quote:
Isn't there an issue when working with threads, or rather processes, and throwing exceptions? I might be wrong though, just remember something like this, perhaps is was the static linking I'm confusing it with.

@alfkil

no since i've deleted the lib from my sdk.. BTW salass00 has linked a thread that show the problem

@afxgroup

Ok.

I'm not sure, that we are talking about the same problem, or?? I don't think there are threads or exceptions involved with my issue. Could be wrong though...

The free() malaise, that I encountered with CMake has spread to qmake also...

For some apparent random reason, a otherwise completely normal call to free() fails with reference to newlib.

Could someone please check, if there is ANY possibility, that there could be a problem with newlib?? If I really have to, I will try and run the same thing with an update 2 to see if it is a new problem with newlib (the exact same procedure has worked flawlessly before with qmake on previous updates).

Help!

Do you have some files compiled with clib2 and some with newlib? This includes any libraries that you're using. Or maybe compiling with newlib and linking with clib2. You cannot mix C runtime libraries.

I have never experienced any trouble with free().

Hans

@Hans

I am 100% not mixing clib2 and newlib. Also it is a curious problem, because it only applies to CMake and qmake and it doesn't happen very often, but when it does it is very consistent. Also note, that I have been using the exact same build steps with a previous update to build a library (libQtDesigner.so), nothing has changed in the build steps, but now I get this error with qmake that wasn't there before...

Is it possible that malloc() and free() are called from different processes? If that is the case then it is obvious that this leads to problems, because newlib handles different memory lists for each opener to be able to release all allocated memory upon program termination.

To be able to malloc() memory in one process and free() the same block in a different process it is necessary to pass NP_Child,TRUE to CreateNewProcess() to make the created process a child of the creating process. After that the interaction of malloc() and free() between these two processes will work.

If that is not possible then you will need to set up some kind of IPC to ensure that all kind of malloc() and free() happens within one process only.

@tboeckel

At least in the case of qmake I'm very sure, that it has nothing to do with processes, because it doesn't have the ability to start processes. In the case of CMake I don't know for sure.

I have though made a small test with qmake, that counts the amount of malloc and free calls, and in this particular case it reaches beyond 32000 individual calls (at least that's how it seems). Maybe there is an upper limit as to how many calls to malloc newlib can handle??

I would be suprised if there were an upper limit to mallocs as these things are generally managed by lists which are unlimited (subject to memory availabilty ofcourse!)

I would try rebuilding the entire project from scratch, ie delete all object code, just to make sure all the files are in sync, if you are building with CMake with CMake you can't be a 100% sure of it till it's been tested, there could be hidden issues with tracking dependencies and other such.

@broadblues

I would be surprised too if it was due to an upper limit of malloc calls, since it doesn't seem to have to do with the size of the project. Eg. smaller projects will fail but larger ones will succeed.

I have tried rebuilding from scratch, and I am quitse sure, that nothing stupid is happening along the way... Especially I'm thinking about defines (-D) passed to the various steps, which are 100% the same all along the way.