I have been developing a C++ application to run on a 64 bit Ubuntu 12.04. I develop the code on my 32 bit 12.04 Ubuntu laptop, then upload it to a git repository, pull it on the server and build the pulled source natively.
Until recently things worked well and I had no problems but today g++ 4.6.3 crashed when I tried to compile on the 64 bit server and I got an output telling me to submit a crash report (g++ 4.6.3 is the same version I have on my development machine also). The identical code did not cause a crash on my dev machine.
I am not asking why it crashed, but I would like to know what the problem was if possible. Does g++ produce any file logs when it encounters problems?
As far as I can tell my code is doing nothing controversial, I am not creating templates, I simply use a couple of boost libraries, mysql++, openssl and some static libraries I have written myself.
I really need to run this application every day so I want to fix this as soon as I can. I can think of the following ways to deal with things
Try and find out what aspect of my code caused the compiler to crash and rewrite my code accordingly.
Rent another server.
Upgrade (or downgrade) g++ or create an additional g++ on the server and try that. I am reluctant to do this as I have read that you can ruin your system when upgrading g++ on Ubuntu.
I use Eclipse to build everything on my dev machine and simply build code on my server using the Eclipse generated makefile that I have made part of the git project - I could write my own makefile in case something in there is causing the crash on the 64 bit server.
I would really welcome advice on how to proceed. I am not an expert on how compilers work internally and this is the first time I have encountered this kind of error so I am not quite sure what to do next.
I would really welcome advice on how to proceed
One reason for a crash might be hardware problem (faulty disk, disk controller, memory, or something else). This is hard to detect.
Another reason might be a compiler bug, but very unlikely.
What you can do is :
check the hardware of the server (run all possible checks you can think of). Try to compile many times on a different machine
make sure your system is not running out of virtual memory
upgrade or change the compiler, and see if it happens
There are various article explaining that g++ can crash because of HW problems :
crash during compiling - Most likely there is nothing wrong with your installation, your compiler or kernel. It very likely has something to do with your hardware. There are two exceptions to this "rule". You could be running low on virtual memory, or you could be installing Red Hat 5.x, 6.x or 7.x
crash during optimization
Related
I am an artist and would like to have access to Monster Mash (https://github.com/google/monster-mash) even if I can't access the web version due to connectivity issues. As such I would like a desktp version, from what I have read on the github page I would just have to compile the code, but I have no idea how I would go about doing this on a windows machine as I am having trouble with downloading or setting up clang or gcc to begin with (Is gcc only for use on Linux). The Linux approach seems much simpler and is (to my eyes) better explained on the github page, so as a side question, I would like to know if I can compile the program in linux for use on windows? thank you so much for any help.
I have Kubuntu 14.10 and 15.04 installed on my four computers, all having different hardware (the oldest machine was assembbled in 2007 and the newest just a month ago. I have both 32- and 64-bit OSs installed. The amount of RAM varies from 4 to 32 GB). I have been using Code::Blocks on them for a few months, and I experience the same problem on all 4 machines: integrated debugger is painfully slow when debugging a C++ program.
After the debugger stops at a breakpoint, it takes 10 seconds to 5 minutes to step through a single line of code. And while the debugger is performing a step, one core of my CPU is loaded by GDB by 100%. And often trying to step through a line of code hangs forever. After that I have to kill GDB and the process that has been debugged.
Some time ago I updated GDB to version 7.9 (from 7.8) but this did not fix the problem. And I have no slowdown when debugging with GDB from command line, so I suspect that the problem is in the Code::Blocks debugger plugin.
I saw many complaints regarding similar problems, some of which were allegedly caused by outdated libc6-dbg (more exactly, by the fact that debug symbols were not shipped with Ubuntu and other Debian-based distributions), but reinstalling libc6-dbg did not help either.
I am afraid that after a day or two of trying to fix this problem I will give up and will switch to Eclipse or some other IDE. It looks like Code::Blocks and its debugger plugin have not been updated for a couple of years (at least, their Linux versions). So maybe I should not use Code::Blocks at all because its future is not clear (while Eclipse is likely to be in service for long time).
I wonder if anybody else experiences this problem and whether there are solutions. Overall Code::Blocks IDE looks decent and rather convenient, but this debugger problem prevents from using it for purposes other than writing code and compiling.
An update:
I ended up installing Eclipse for C++ (Luna release). It took some time to learn how to use it. It is slow, buggy, glitchy and uses a lot of RAM, but it at least allows me to debug my applications in IDE. Now I am 100% sure that the problem is in Code::Blocks debugger plugin.
I also tried NetBeans, and seems to work fine, but it is even slower than Eclipse and looks really ugly. So I am going to stick with Eclipse for now because no one seems to be willing to fix the debugger plugin in Code::Blocks.
The problem turned out to be with stepping through lines that declare uninitialized std::string objects. A similar (or the same) problem is described here:
https://sourceware.org/bugzilla/show_bug.cgi?id=12555
The probleb with debugging in Code::Blocks was suddenly fixed when I followed these instructions:
http://wiki.eclipse.org/CDT/User/FAQ#How_can_I_inspect_the_contents_of_STL_containers.3F
on how to enable pretty-printing in Eclipse CDT.
I still need to follow these instructions on my other machines to make sure they fix the problem.
You can try and turn off CodeBlock pretty-printing: Settings->Debugger->Default->Enable Watch Scripts = Unchecked
(Source)
I recently noticed that running a program inside gdb in windows makes it a lot slower, and I want to know why.
Here's an example:
It is a pure C++03 project, compiled with mingw32 (gcc 4.8.1, 32 bits).
It is statically linked against libstdc++ and libgcc, no other lib is used.
It is a cpu and memory intensive non-parallel process (a mesh edition operation, lots of news and deletes and queries to data structures involved).
The problem is not start-up time, the whole process is painfully slow.
Debug build (-O0 -g2) runs in 8 secs outside gdb, but in 140 secs within gdb.
Tested from command line, just launching gdb and just typing "run" (no breakpoints defined).
I also tested a release build (optimized, and without debugging information), and it is still much slower inside gdb (3 secs vs 140 secs; yes, it takes the same time as the not optimized version inside gdb).
Tested with gdb 7.5 and 7.6 from mingw32 project, and with a gdb 7.8 compiled by me (all of them without python support).
I usually develop on a GNU/Linux box, and there I can't notice speed differences between running with or withoud gdb.
I want to know what is gdb doing that is making it run so slowly. I have some basic understanding of how a debugger works, but I cannot figure out what is it doing here, and googling didn't helped me this time.
I've finally found the problem, thanks to greatwolf for asking me to test other debuggers. Ollydbg takes the same time as gdb, so it's not a gdb problem, its a Windows problem. This tip changed my search criteria and then I've found this article* that explains the problem very well and gives a really simple solution: define an environment varible _NO_DEBUG_HEAP to 1. This will disable the use of a special heap system windows provides and c++ programs use.
* Here's the link: http://preshing.com/20110717/the-windows-heap-is-slow-when-launched-from-the-debugger/
I once had issues with gdb being incredibly slow and I remember disabling nls (native language support, i.e. the translations of all the messages) would remedy this.
The configure time option is --disable-nls. I might have just been mistaken as to what is the true cause, but it's worth a shot for you anyways.
My bug report from back then is here, although the conclusion there would be that I was mistaken. If you can provide further insight into this, that would be great!
I am required to write a C++ application to run on an embedded Linux setup (DMP Vortex86DX processor). The vendor provides a minimal linux installation image that can be installed to the board and contains appropriate hardware drivers. My question is motivated by the answer to my previous question about writing Linux software on a particular kernel to run on a different kernel . I don't really know where to start when it comes to writing the software with regards to ensuring compatibility.
My instinctive approach would be to install the same versions of g++ on the embedded device and on my desktop development machine, write the application on the dev maching, copy to the board and compile it there. This seems madness though and I find it hard to believe that this is how embedded software is developed. With regards to the answer to my previous question, is there a way I can simply build on my desktop but use the version of glibc that exists on the embedded device - if so how can enforce linkage to a specific version? Or is it possible to build everything statically so that the application doesn't link to anything dynamically (I doubt this is possible).
I am a total novice to embedded development, and foresee months of frustration unless I can get hold of some good advice or resources. Any pointers or suggestion of where to start will be very gratefully received no matter how simple or trivial they seem - I really am starting at the very bottom with regards to embedded stuff.
OK, given the fact that the Vortex86SX/DX/MX claims to be x86 compatible, a small set of compiler switches should enable you to compile code for your target machine: -m32 to ensure 32bit code, and no -march switch targeting a specific CPU.
Then you'll need to link your code. As long as you don't use anything fancy, but simple established glibc functions, I'd expect the ABI to be the same on your development machine and the embedded system. In other words, you compile against your host libraries, copy the binary to the embedded system, and it should simply run using the libraries available there.
If X-Linux were to use some other libc, like uclibc or similar, then you'd need a cross compiler on your host. I have little experience with Ubuntu in that regard, but I know that the sys-devel/crossdev package for Gentoo linux makes generation of cross-compilers very easy. This can be both for different architectures (not needed in your case) and different libraries (like e.g. uclibc).
I'd say simply give copying the binaries a try, and report back if you encounter any problems there.
This question may seem blindingly obvious and I realise I am putting myself up for a large number of downvotes but I am very new to Linux dev and have only been working on it for a while.
I have been writing an application on ubuntu 12.04 (kernel 3.2.0) in C++ then copying this via scp to an ubuntu 8.04 (kernel 2.6.30) installation on another device. I have been noticing some very strange behaviour that I simply cannot explain. I have naively assumed that I can run this executable on a previous version, but it is beginning to dawn on me that this in fact may not be the case. In future must I ensure that the Linux version I build my application on is identical to that which it will be running on in the field?? Or must I actually build the application from source code directly on the device it will be running on??? I am very new to Linux dev but not new to C++ so I realise that this question may seem facile, but this is the kind of issue that I have simply not seen in books/tutorials etc.
Most of the time, it's not the kernel that stops you, it's glibc.
glibc is backwards compatible, meaning programs compiled and linked to an older version will work exactly the same with a newer version at runtime. The other way around is not that compatible.
Best is of course to build on the distro you want to run it. If you can't do that, build on the one with the oldest glibc install.
It's also very hard to build and link to an older glibc than the system glibc, installing/building glibc tends to mess up your system more than it's worth. Set up a VM with an old Linux, and use that instead.