More Dinkum issues - cin this time

QNX Newsgroups (Archives) qdn.public.qnxrtp.os
1

I have another apparent Dinkum libs problem.

I have a situation where a particular executable is failing to get cin
initialised correctly. I can see in the Debugger that
ios_base::Init::Init(void) is getting called (which is in libcpp.so.2a), but
after this completes cin is not correctly initialised, and any attempt to
access it causes a SIGSEGV.

I can see that cin is incorrect as soon as ios_base::Init::Init()
completes - so there is no opportunity for this memory to have got stomped
by some other bad code. It looks like something is going wrong internally in
ios_base::Init::Init().

This does not happen for all executables, only some. Yes, I am currently
trying to narrow the problem down as to the differences between the
executables that work and those that don’t, but after two days of
frustration I have got nowhere. No, I can’t produce a “simple” test case
that fails.

If I recompile with the GNU/GCC libs the problem goes away.

So:

  • has anyone else seen anything similar?
  • is it possible to see the source to ios_base::Init::Init() to try to get
    some idea of what might be going wrong?
  • Any other suggestions on how to track this down? Is there a trick to get
    symbols visible within the .so libraries within ddd?
  • Is anyone else finding the Dinkum libs to be generally unstable, or have
    we just been desparately unlucky to have two issues within a week?

Rob Rutherford
Ruzz Technology

2

Hi Robert,

I hope that you’ve been desperately unlucky. We’ve generally had very few
complaints about the Dinkum libs and headers. Our Dinkum C++ expert is home
sick today but I’ll ping him and see if he can find out if there are any
known issues in this area when he gets back.

cheers,

Kris

“Robert Rutherford” <ruzz@NoSpamPlease.ruzz.com> wrote in message
news:ah38qb$qth$1@inn.qnx.com…

I have another apparent Dinkum libs problem.

I have a situation where a particular executable is failing to get cin
initialised correctly. I can see in the Debugger that
ios_base::Init::Init(void) is getting called (which is in libcpp.so.2a),
but
after this completes cin is not correctly initialised, and any attempt to
access it causes a SIGSEGV.

I can see that cin is incorrect as soon as ios_base::Init::Init()
completes - so there is no opportunity for this memory to have got stomped
by some other bad code. It looks like something is going wrong internally
in
ios_base::Init::Init().

This does not happen for all executables, only some. Yes, I am currently
trying to narrow the problem down as to the differences between the
executables that work and those that don’t, but after two days of
frustration I have got nowhere. No, I can’t produce a “simple” test case
that fails.

If I recompile with the GNU/GCC libs the problem goes away.

So:

  • has anyone else seen anything similar?
  • is it possible to see the source to ios_base::Init::Init() to try to get
    some idea of what might be going wrong?
  • Any other suggestions on how to track this down? Is there a trick to get
    symbols visible within the .so libraries within ddd?
  • Is anyone else finding the Dinkum libs to be generally unstable, or have
    we just been desparately unlucky to have two issues within a week?

Rob Rutherford
Ruzz Technology

3

OK I’ve managed to reduce this to a pretty trivial test case.

The following program will crash (SIGSEGV) on the first access to cin.
Comment-out the indicated line and it will work. Use the GNU/GCC libs and it
will work

Now we’re really screwed.
We can’t use strstream (it has a memory leak) - stringstream is the
workaround.
But now we can’t use stringstream (it causes cin to crash).
Looks like we’ll have to stop using Dinkum at all, at least until some of
these bugs are fixed.

Robert Rutherford

===========================================================
// Test to show cin corruption
// Compile with QCC -o cin cin.cc

#include
#include
#include

using namespace std;

int main( int argc, char *argv[] ) {

string testcin;

cout << “Waiting for input…” << endl;
cin >> testcin;
cout << "Read word " << testcin << endl;

// Comment-out this line and it doesn’t crash
istringstream crash;

}

“Kris Warkentin” <kewarken@qnx.com> wrote in message
news:ah48rm$lc6$1@nntp.qnx.com…

Hi Robert,

I hope that you’ve been desperately unlucky. We’ve generally had very few
complaints about the Dinkum libs and headers. Our Dinkum C++ expert is
home
sick today but I’ll ping him and see if he can find out if there are any
known issues in this area when he gets back.

cheers,

Kris

“Robert Rutherford” <> ruzz@NoSpamPlease.ruzz.com> > wrote in message
news:ah38qb$qth$> 1@inn.qnx.com> …
I have another apparent Dinkum libs problem.

I have a situation where a particular executable is failing to get cin
initialised correctly. I can see in the Debugger that
ios_base::Init::Init(void) is getting called (which is in libcpp.so.2a),
but
after this completes cin is not correctly initialised, and any attempt
to
access it causes a SIGSEGV.

I can see that cin is incorrect as soon as ios_base::Init::Init()
completes - so there is no opportunity for this memory to have got
stomped
by some other bad code. It looks like something is going wrong
internally
in
ios_base::Init::Init().

This does not happen for all executables, only some. Yes, I am currently
trying to narrow the problem down as to the differences between the
executables that work and those that don’t, but after two days of
frustration I have got nowhere. No, I can’t produce a “simple” test case
that fails.

If I recompile with the GNU/GCC libs the problem goes away.

So:

  • has anyone else seen anything similar?
  • is it possible to see the source to ios_base::Init::Init() to try to
    get
    some idea of what might be going wrong?
  • Any other suggestions on how to track this down? Is there a trick to
    get
    symbols visible within the .so libraries within ddd?
  • Is anyone else finding the Dinkum libs to be generally unstable, or
    have
    we just been desparately unlucky to have two issues within a week?

Rob Rutherford
Ruzz Technology

\

4

Robert Rutherford wrote:

OK I’ve managed to reduce this to a pretty trivial test case.

The following program will crash (SIGSEGV) on the first access to cin.
Comment-out the indicated line and it will work. Use the GNU/GCC libs and it
will work

Now we’re really screwed.
We can’t use strstream (it has a memory leak) - stringstream is the
workaround.
But now we can’t use stringstream (it causes cin to crash).
Looks like we’ll have to stop using Dinkum at all, at least until some of
these bugs are fixed.

It gets better.

The following program crashes simply by “#including”

#include
#include
#include // comment out and program works as expected
using namespace std; // … as is, crashes at “cin >> testcin”.

int main(int argc, char *argv[])
{
string testcin;

cout << “Waiting for input…\n”;
cin >> testcin;
cout << "Read word " << testcin << ‘\n’;
}

Compiled under 6.2 using “QCC -o crsh crsh.cc”

The odd thing is that I am currently using strstream successfully in a
non-trivial app.

5

Was this ever resolved? I’ve just been stung by it.

–
Marty Doane
Siemens Dematic


“Rennie” <rallen@csical.com> wrote in message
news:ah6n0n$86n$1@tiger.openqnx.com…

Robert Rutherford wrote:

OK I’ve managed to reduce this to a pretty trivial test case.

The following program will crash (SIGSEGV) on the first access to cin.
Comment-out the indicated line and it will work. Use the GNU/GCC libs
and it
will work

Now we’re really screwed.
We can’t use strstream (it has a memory leak) - stringstream is the
workaround.
But now we can’t use stringstream (it causes cin to crash).
Looks like we’ll have to stop using Dinkum at all, at least until some
of
these bugs are fixed.

It gets better.

The following program crashes simply by “#including” <strstream

#include <string
#include <iostream
#include // comment out and program works as expected
using namespace std; // … as is, crashes at “cin >> testcin”.

int main(int argc, char *argv[])
{
string testcin;

cout << “Waiting for input…\n”;
cin >> testcin;
cout << "Read word " << testcin << ‘\n’;
}

Compiled under 6.2 using “QCC -o crsh crsh.cc”

The odd thing is that I am currently using strstream successfully in a
non-trivial app.

6

Yes, it was a problem with the version of the Dinkum libs shipped with
6.2.0. We got sent an “experimental” version of libcpp.so.2a that fixed it.

It should be fixed in 6.2.1 but I think a workaround was to use the old
libcpp.so.2 rather than libcpp.so.2a

Rob Rutherford
Ruzz Technology

“Marty Doane” <marty.doane@rapistan.com> wrote in message
news:avmlej$g3m$1@inn.qnx.com…

Was this ever resolved? I’ve just been stung by it.

–
Marty Doane
Siemens Dematic


“Rennie” <> rallen@csical.com> > wrote in message
news:ah6n0n$86n$> 1@tiger.openqnx.com> …
Robert Rutherford wrote:

OK I’ve managed to reduce this to a pretty trivial test case.

The following program will crash (SIGSEGV) on the first access to cin.
Comment-out the indicated line and it will work. Use the GNU/GCC libs
and it
will work

Now we’re really screwed.
We can’t use strstream (it has a memory leak) - stringstream is the
workaround.
But now we can’t use stringstream (it causes cin to crash).
Looks like we’ll have to stop using Dinkum at all, at least until
some
of
these bugs are fixed.

It gets better.

The following program crashes simply by “#including” <strstream

#include <string
#include <iostream
#include // comment out and program works as expected
using namespace std; // … as is, crashes at “cin >> testcin”.

int main(int argc, char *argv[])
{
string testcin;

cout << “Waiting for input…\n”;
cin >> testcin;
cout << "Read word " << testcin << ‘\n’;
}

Compiled under 6.2 using “QCC -o crsh crsh.cc”

The odd thing is that I am currently using strstream successfully in a
non-trivial app.
\