Want to debug this?

[woodbrian77]

Maybe you can motivate me to debug the following scenario:

Gcc-built version of my middle tier asserts

assert(!pendingTransactions.empty());

in transitional context.

If I start the back tier, start clang-built middle tier
and then run some tests, everything works fine.

If I start the back tier, start gcc-built middle tier
and then run some tests, everything again works fine.

If I start the back tier, start clang-built middle tier,
run some tests, stop clang-built middle tier and start
gcc-built middle tier and run the tests, it asserts as
mentioned.

If I start the back tier, start gcc-built middle tier,
run some tests, stop gcc-built middle tier and start
clang-built middle tier and run some tests everything
works fine. If I go on and stop clang-built middle
tier and start gcc-built middle tier and run tests,
the assert happens.

I'm not sure if it's worth debugging. I'm using gcc
4.8.1 and clang 3.3 on Linux. I have a machine that
has gcc 4.8.2 on it, but haven't tested it on there.
I've been thinking of moving to newer software (OS
and compilers) on the machine I have the problem on,
so the "problem" might go away that way too.


Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net

 

[woodbrian77]

If I start the back tier, start gcc-built middle tier,
run some tests, stop gcc-built middle tier and start
clang-built middle tier and run some tests everything
works fine.

On further analysis I'm able to produce the problem
with a clang-built middle tier sometimes.

I'm not able to reproduce it when I keep the middle
tier running though. It only happens after I've stopped
the middle tier and restarted it.

 

[woodbrian77]

Your posts are inane as they require insight into your code which nobody
except yourself has insight into. You seem to be blissfully unaware of
this fact. Even if we ignore this crucial oversight one still has to
wonder why you think anyone would learn your code and debug it for you
for free.

Perhaps because they think what I'm working on is interesting.
Some may be waiting for a ship more to their liking to come
along and others may realize that's unlikely.

Here is a clue: create a simple dependency free test case which
manifests your problem and can be compiled by anyone without the need to
download megabytes of crap.

I don't have megabytes of anything to download. The downloadable
part is currently 21,148 bytes.

 

[woodbrian77]

On Saturday, December 7, 2013 7:34:41 AM UTC-6, Leigh Johnston wrote:

Please don't swear here. I was thinking, "At least Leigh
hasn't been swearing here" before that post.

I have a 3-tier system. The back and middle tiers are
servers. The front tier exits after it has either
succeeded or failed. I think a lot of people here
know that and those that don't could find it on my
website.


Brian
Ebenezer Enterprises -
"Because you have a mother and a father " from
"The Design and Evolution of C++"

 

[Ike Naar]

I have a 3-tier system. The back and middle tiers are
servers.

The front tier is not a server?

 

[woodbrian77]

The front tier is not a server?

Correct. It runs and then exits.

I may be having some file system corruption. Today
I noticed a couple of files in my directory with
goofy names and both are over a megabyte in size.
The files were created yesterday when I was testing
this stuff. This is kind of pushing me towards
moving to a newer OS. I think I've been on this
version of the OS for over 5 months.

 

[woodbrian77]

Gosh Leigh, I think most people would find such an opening statement very
offensive.

I think he disagrees with the idea that children deserve
to have a father and mother.

http://www.dennisprager.com/mary-cheney-liz-cheney-left-wing-hate/

 

[David Brown]

"Juha Nieminen" wrote in message

And what exactly does this have to do with the article that was posted
with the comment you attempted to ridicule?

(Obviously this post is for many people here, not just you.)

Could this be moved to a different thread? I enjoy an off-topic
discussion like this as much as the next person, and I think that
ridiculous ideas should be ridiculed (but one should not necessarily
ridicule the person with those ideas). But perhaps Brian should also be
allowed to have a thread about C++ without it descending into
name-calling and a repeat of exactly the same points from before?

 

[woodbrian77]

This is kind of pushing me towards
moving to a newer OS. I think I've been on this
version of the OS for over 5 months.

I wound up going to an older version of Linux in Debian.

I rebuilt all three tiers on Debian and tested them on
Debian. I couldn't reproduce the problem when running
on Debian.

Then I copied the Debian-built files to a Fedora machine
where I had originally encountered the problem. The
problem still occurred on Fedora. The Fedora machine
has an alpha or beta version of Fedora on it and my
guess is it has a TCP related bug.

 

[Geoff]

I wound up going to an older version of Linux in Debian.

I rebuilt all three tiers on Debian and tested them on
Debian. I couldn't reproduce the problem when running
on Debian.

Then I copied the Debian-built files to a Fedora machine
where I had originally encountered the problem. The
problem still occurred on Fedora. The Fedora machine
has an alpha or beta version of Fedora on it and my
guess is it has a TCP related bug.

Generally speaking, it's a Bad Idea(tm) to copy binaries from one
edition of Linux (Debian) to another (Fedora). The results are
unpredictable since they may not share a common ABI. It can be done
successfully but doing so while trying to "debug" your stated problem
is just adding another kind of potential error into the scenario.

Instead, you should copy your sources over and build your projects on
each platform. This is why package management exists.

"Alpha or beta" version is meaningless in this context. The current
stable supported release of Fedora is 19. Fedora 20 is available in
alpha and beta releases but why would you introduce yet another set of
problems into the mix?

In your original problem statement you also say you're using clang and
gcc projects. Why? If they share libraries you are running the risk of
ABI incompatibility again. Choose a tool (clang) and bring your
gcc-compiled project up to date and compile all your related projects
with the same tools.

 

[Jorgen Grahn]

Generally speaking, it's a Bad Idea(tm) to copy binaries from one
edition of Linux (Debian) to another (Fedora). The results are
unpredictable since they may not share a common ABI.

Are you reasonably sure about that? Any references?

The main burden of keeping things sane lies on the library writers.
When an incompatible version of e.g. the Gnu libc comes out, they must
step the .so file's revision number. (Somehow. The details are
unclear to me.) Then your program will fail to run unless the right
version of libc is available.

It's possible that Fedora takes libfoo version X from upstream and
modifies it so it's not compatible with the Debian build of libfoo
version X ... or modifies the compiler so that it generates such an
incompatibility. But that seems to me rather unlikely since it means
messing with the rather delicate upstream ABI decisions. If you're
Fedora, your can only switch ABIs when the upstream does it, and then
you're stuck with that decision until they release libfoo version X+1.

....

Instead, you should copy your sources over and build your projects on
each platform. This is why package management exists.

I agree that is the sane and normal way of doing it. And yes, that
also means I'm not sure you are wrong.

/Jorgen

 

[woodbrian77]

Generally speaking, it's a Bad Idea(tm) to copy binaries from one
edition of Linux (Debian) to another (Fedora). The results are
unpredictable since they may not share a common ABI. It can be done
successfully but doing so while trying to "debug" your stated problem
is just adding another kind of potential error into the scenario.


Instead, you should copy your sources over and build your projects on
each platform. This is why package management exists.

I have one production machine and a couple of development
machines. As a security measure, I don't copy sources
for the back tier to the production machine. Up until
a few days ago both the production and development
machines had Fedora 20 installs on them. Anyway, I tend
to keep the development and production machines within
a release of each other and haven't encountered problems
from doing things that way.

I only introduced the Debian install in order to
investigate the problem.

In your original problem statement you also say you're using clang and
gcc projects. Why? If they share libraries you are running the risk of
ABI incompatibility again. Choose a tool (clang) and bring your
gcc-compiled project up to date and compile all your related projects
with the same tools.

I haven't so far been able to make a decision between clang
and gcc. I've continued to use both in part to figure out
which one I thought was better. On Debian, the compilers
are clang 3.0-6.2 and gcc 4.7.2-5. My software only builds
with gcc on Debian, but on Fedora it builds with both
compilers.

 

[Melzzzzz]

On Sun, 15 Dec 2013 16:17:02 -0800 (PST)

I haven't so far been able to make a decision between clang
and gcc.

Stick with gcc as it more mature (has less bugs).
I have bad experience with clang and FreeBSD 10...

 

[woodbrian77]

a few days ago both the production and development
machines had Fedora 20 installs on them.

Oops, one of my machines has Fedora 19 on it.

 

[Geoff]

Are you reasonably sure about that? Any references?

The main burden of keeping things sane lies on the library writers.
When an incompatible version of e.g. the Gnu libc comes out, they must
step the .so file's revision number. (Somehow. The details are
unclear to me.) Then your program will fail to run unless the right
version of libc is available.

It's possible that Fedora takes libfoo version X from upstream and
modifies it so it's not compatible with the Debian build of libfoo
version X ... or modifies the compiler so that it generates such an
incompatibility. But that seems to me rather unlikely since it means
messing with the rather delicate upstream ABI decisions. If you're
Fedora, your can only switch ABIs when the upstream does it, and then
you're stuck with that decision until they release libfoo version X+1.

...

I agree that is the sane and normal way of doing it. And yes, that
also means I'm not sure you are wrong.

That's OK. I'm not sure I'm right. I only know that if I'm
debugging a system, I don't go around transplanting it onto other
systems to see what else will break besides the problem I'm working on
already. That way lies madness...