I've written a program that simulates a simple mail server. All good while testing on my local computer. But program fails when I upload it to the testing environment and displays the following error: "Abnormal program termination (Segmentation fault/Bus error/Memory limit exceeded/Stack limit exceeded)". I'm using AVL tree and have re-written program twice, first using recursion and after -iterative search and insertion. But both ended up with the same issue (

Can you please have a look and share your ideas where the issue can be? Will appreciate your feedback.
<code removed>

Update: thank you for your comments. I understand now that it was hard to expect specific advices as I was not able to upload the whole program with test data (was too long for here). Also it was important to mention that there were some limitations set (as this was a training task in making deep/shallow copies). Will keep this as a lessons learnt for future.

For those who are interested in the outcome: the issues were with nullptrs and not checking boundaries. Simple debug went well but when I started testing edge cases, found the root causes for errors.

Asking others to build, test and debug your complete program without even saying under what conditions it fails is asking a little bit much.

Telling us that you have rewritten the program twice is also not useful to others understanding of your problem. Why did you rewrite it rather than troubleshoot it?

Telling us what you have done to troubleshoot and isolate the problem would be more helpful.

Please review the Site FAQ for guidance in asking well formed questions. Especially visit the link from that page, How to Ask Questions the Smart Way for discussion of things to consider when asking others for help.

May be I was not clear enough, sorry about that. BUT

I don't ask to debug - as I have written that on a local computer there are no errors, all works fine.

The problem appears when loading code into the testing environment. And yes, I have no idea under what conditions this error happens because this Abnormal termination error message is the only feedback I get ((.

I have re written it in order to move from recursion to iterative search and insertion, to optimize memory use. But it resulted in the same error message.

The goal of this post was to get feedback, if possible, about any wrong use one might see there. Or eg advice on optimizing performance of AVL search/insertion

Uhm, am I missing something? All the program does is allocate three arrays on the stack.

If everything you're saying is true and you've posted all you need to, then either there's something wrong with the "testing environment's" RAM, or there's something very important about it that you're not telling us (e.g. that it's some sort of retro computer or other memory-constrained environment).

If that is not the case and you've simply omitted information, then build the program with debugging symbols, and run gdb or lldb on it when it's in the testing environment. The backtrace will tell you where the infinite recursion is (if it is that).

Also, don't forget to check the "testing environment's system logs. Such as "dmesg", if it's Linux. I mean, maybe the OOM-killer killed it.

2 members found this post helpful.

The program in post #1 works faultlessly for me (after removing some preprocessor-lines). Though it doesn't actually do anything.

Edit: valgrind(1) can point out the bugs in the code. Here is a simple correction:

that may mean an incompatible library (.so file) or something else. But anyway I would try to use valgrind on your code.

Though I think newNode should be dropped, insted the Node constructor(s) should initialize every field.

Does this error code mean: "Segmentation fault or Bus error or Memory limit exceeded or Stack limit exceeded" ??

What is the error code? Please post exactly what you get on your console when you try it.

Why are you implementing an AVL tree when there are already existing container classes (I believe, even in the standard libraries) which are known to implement them correctly? "Writing data structure implementations by hand" are things we're only forced to do at University. Over at "github.com," my search produced 716 results.

(Sounds like some kind of contest or exam task.)

@NevemTeve: I'm not so sure.

My guess is that there's actually a bug in this person's implementation, possibly caused by the freeing of memory resources, which is not apparent on the development machine with its probably-bottomless resources. The ulimit command can sometimes be used to cause these bugs to appear on a "dev box," but I've had somewhat mixed success with it.

Nevertheless – if there is any sort of "complicated data structure" which someone else(!) has already encapsulated in a trustworthy "container class," my strong recommendation to any C++ programmer is: "use the container class." Don't look inside of it: "you frankly don't care how the damn thing works, as long as you know that it does." In addition to what you know to be supplied by the "standard libraries" of your chosen compiler, GitHub and SourceForge are usually good sources of stuff that "somebody else has already debugged."

The reason why you are writing this program is to mock the behavior of a mail server – not to correctly (re-)implement "an AVL tree."

(P.S.: I presume that you did your online research at the places aforementioned, to see if somebody else(!!) has not already implemented a "mock mail server?" ... Just askin' ... Whups, my GitHub query just listed 33 results, not all of them applicable.)

That would be std::set and std::map, both of which are implemented as red-black trees.

Also seems like Original Poster has lost interest in the topic.
Off: I have a Balanced Binary Tree (BaBiT) implementation written in C which is freely available. (No direct link here, can be found on sourceforge.net)

@NevemTeve: I certainly wouldn't consider it to be "advertising," and I'd encourage you to edit your post to include the link. But it sounds like an excellent thing to contribute to GitHub ... where it would most easily be found.

1 members found this post helpful.