Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
85 user(s) are online (53 user(s) are browsing Forums)

Members: 0
Guests: 85

more...

Support us!

Headlines

 
  Register To Post  

Annoying problem with free() (newlib) [spreading quickly...]
Just can't stay away
Just can't stay away


See User information
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!


Edited by alfkil on 2011/11/4 21:57:29
Go to top
Re: Annoying problem with std::vector
Just can't stay away
Just can't stay away


See User information
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... ;-(

Go to top
Re: Annoying problem with std::vector
Home away from home
Home away from home


See User information
@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

Join us to improve dopus5!
AmigaOS4 on youtube
Go to top
Re: Annoying problem with std::vector
Amigans Defender
Amigans Defender


See User information
Quote:

Anyone, please give me a push!

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

ExecSG Team Lead
Go to top
Re: Annoying problem with std::vector
Amigans Defender
Amigans Defender


See User information
Quote:

It doesn't help me much though... What does "throw" mean??

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:

And what is the scope of the "delete operator"??

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.

ExecSG Team Lead
Go to top
Re: Annoying problem with std::vector
Just can't stay away
Just can't stay away


See User information
@ssolie

Quote:

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.


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

Link to thread

Go to top
Re: Annoying problem with std::vector
Amigans Defender
Amigans Defender


See User information
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.

i'm really tired...
Go to top
Re: Annoying problem with std::vector
Just can't stay away
Just can't stay away


See User information
@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.

Go to top
Re: Annoying problem with std::vector
Just popping in
Just popping in


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

Link to thread

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.

Go to top
Re: Annoying problem with std::vector
Amigans Defender
Amigans Defender


See User information
@alfkil

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

i'm really tired...
Go to top
Re: Annoying problem with std::vector
Just can't stay away
Just can't stay away


See User information
@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...

Go to top
Re: Annoying problem with std::vector
Just can't stay away
Just can't stay away


See User information
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!

Go to top
Re: Annoying problem with std::vector
Home away from home
Home away from home


See User information
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

http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more.
https://keasigmadelta.com/ - more of my work
Go to top
Re: Annoying problem with std::vector
Just can't stay away
Just can't stay away


See User information
@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...

Go to top
Re: Annoying problem with std::vector
Just popping in
Just popping in


See User information
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.

Why stop it now, just when I am hating it?

Thore Böckelmann
Go to top
Re: Annoying problem with std::vector
Just can't stay away
Just can't stay away


See User information
@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??

Go to top
Re: Annoying problem with std::vector
Home away from home
Home away from home


See User information
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.




Go to top
Re: Annoying problem with std::vector
Just can't stay away
Just can't stay away


See User information
@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.

Go to top

  Register To Post

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project