By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,286 Members | 2,422 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,286 IT Pros & Developers. It's quick & easy.

new () keeps core-dump instead of generating exception

P: n/a
Hi, all,

I am trying to allocate some objects during application starts up. The
objects are created through new operator, but for some reason, the
application keeps crashing and here is the debug trace:
(gdb) where
#0 0xb64349dd in _int_malloc () from /lib/tls/libc.so.6
#1 0xb6433ced in malloc () from /lib/tls/libc.so.6
#2 0xb659789e in operator new () from /usr/lib/libstdc++.so.5

I am using redhat Linux 2.4.21-15.ELsm, any idea why is that?
Mar 6 '08 #1
Share this Question
Share on Google+
6 Replies


P: n/a
On Thu, 06 Mar 2008 20:00:37 +0100, we*****@yahoo.com <we*****@yahoo.com>
wrote:
Hi, all,

I am trying to allocate some objects during application starts up. The
objects are created through new operator, but for some reason, the
application keeps crashing and here is the debug trace:
(gdb) where
#0 0xb64349dd in _int_malloc () from /lib/tls/libc.so.6
#1 0xb6433ced in malloc () from /lib/tls/libc.so.6
#2 0xb659789e in operator new () from /usr/lib/libstdc++.so.5

I am using redhat Linux 2.4.21-15.ELsm, any idea why is that?

Without some code, we can't help you .
Mar 6 '08 #2

P: n/a
On 2008-03-06 20:00, we*****@yahoo.com wrote:
Hi, all,

I am trying to allocate some objects during application starts up. The
objects are created through new operator, but for some reason, the
application keeps crashing and here is the debug trace:
(gdb) where
#0 0xb64349dd in _int_malloc () from /lib/tls/libc.so.6
#1 0xb6433ced in malloc () from /lib/tls/libc.so.6
#2 0xb659789e in operator new () from /usr/lib/libstdc++.so.5
In addition to what David said:

Either you have a bad version of libc (not likely) or the problem is in
stack-frame not shown in the above backtracer, find the stack-frame
which is in your code and start looking there.

--
Erik Wikström
Mar 6 '08 #3

P: n/a
On Mar 7, 2:20*am, Erik Wikström <Erik-wikst...@telia.comwrote:
On 2008-03-06 20:00, wenm...@yahoo.com wrote:
Hi, all,
I am trying to allocate some objects during application starts up. The
objects are created through new operator, but for some reason, the
application keeps crashing and here is the debug trace:
(gdb) where
#0 *0xb64349dd in _int_malloc () from /lib/tls/libc.so.6
#1 *0xb6433ced in malloc () from /lib/tls/libc.so.6
#2 *0xb659789e in operator new () from /usr/lib/libstdc++.so.5

In addition to what David said:

Either you have a bad version of libc (not likely) or the problem is in
stack-frame not shown in the above backtracer, find the stack-frame
which is in your code and start looking there.

--
Erik Wikström
as said by others, we need some code as to what/where/how you are
using new. Anyways, new should throw an exception on failure. my guess
is that are you catching the bad allocation exception??
for genericity you may use catch(...) as uncaught exceptions tend to
dump core, atleast in the platforms i have used(aix & sun).

Thanks,
Balaji.
Mar 7 '08 #4

P: n/a
On Mar 6, 8:00 pm, "wenm...@yahoo.com" <wenm...@yahoo.comwrote:
I am trying to allocate some objects during application starts up. The
objects are created through new operator, but for some reason, the
application keeps crashing and here is the debug trace:
(gdb) where
#0 0xb64349dd in _int_malloc () from /lib/tls/libc.so.6
#1 0xb6433ced in malloc () from /lib/tls/libc.so.6
#2 0xb659789e in operator new () from /usr/lib/libstdc++.so.5
I am using redhat Linux 2.4.21-15.ELsm, any idea why is that?
Any idea as to why you're using redhat Linux, no.

If you meant why you're crashing, it's impossible to say, but in
general, supposing that you've linked in the right versions of
everything, it's probable that you've mucked up the free store
arena with some illegal memory writes earlier. (Or, as someone
else suggested, you've requested more memory than is available,
and aren't catching the exception---and possibly cannot catch
it, if you're still running static initializers.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Mar 7 '08 #5

P: n/a
Two things you can try:
1. As suggested by Balaji above, use catch(...)

2. Use the "nothrow" version of new:
e.g.
int *i = new (nothrow) int[10];
if(i==NULL)
{
cout << "see if it comes here" << endl;
}
Mar 7 '08 #6

P: n/a
On 7 mar, 15:05, Shobhit Gupta <shobhitgupt...@gmail.comwrote:
Two things you can try:
1. As suggested by Balaji above, use catch(...)
Where? He said that it was during program start-up, which I
understand to mean before main.
2. Use the "nothrow" version of new:
e.g.
int *i = new (nothrow) int[10];
if(i==NULL)
{
cout << "see if it comes here" << endl;
}
If new is crashing, then that probably won't change anything.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Mar 7 '08 #7

This discussion thread is closed

Replies have been disabled for this discussion.