Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
On Sun, 6 Feb 2000, Brad Noyes wrote: > I'm writing a c++ program that before i changed distributions from RH6.0, to > Mandrake worked. But now i try to run it i get a Segmentation fault when i > execute it with no core dump. Seg faults: the wonderful, wonderful sign of memory leaks. aaahhhh.. You're probably doing one of two things: first, you might be allocating memory and forgetting to free it again when you are finished (less likely), or using some bit of memory before you allocate it (more likely). For an example of the latter, here's some C code: int main() { int *ret_param; some_function_call(1, 13, ret_param); exit; } The problem here is that you don't really know what ret_param really is until you do a malloc (or a new). It's the right type, but you could be pointing anywhere. What changes from RH6.0 to Mandrake? As someone else pointed out, libraries. Your libraries now occupy different spaces in logical memory (how the app sees memory space). This happens because the libraries are just different; even with the same source, Mandrake compiles with pentium optimizations. Thus, a pointer reference that worked before - because it pointed to nowhere - might now no longer work because it points to a library. > Is there anyway that i can figure out why it is > seg faulting with gdb, or something? gdb might help with a core dump; more on that in a moment. Just running it under gdb probably won't help you much; in my experience gdb tends to alter the memory map enough for freaky memory problems to suddenly not be problems anymore. What to do then? First, listen for warnings! The compiler really means those warnings (even if the Apple compiler has fun messages like 'Found /* within a comment, this worries me...'). Compile the program with a -Wall (all warnings). This will give you a lot, but it tends to make your program work better. What else? I can't remember the name, but there is a library that you can link against that provides a malloc/free/etc. that tracks memory and tells you when you've been playing with uninitialized memory. Search freshmeat for that. > And why wouldn't this seg fault yield a > core dump? I can usually tell what is wrong when there's a core dump. The easy solution: ulimits. Try issuing the command 'ulimit' at a prompt. You'll get a list of (user/unix?) limits for various things; one of them is coredumpsize. Try a 'ulimit coredumpsize unlimited' and then run your program. Then you should be able to load the coredump into gdb - check the docs; I have to every time I want to check a core. Cheers, --Mark - Subcription/unsubscription/info requests: send e-mail with "subscribe", "unsubscribe", or "info" on the first line of the message body to discuss-request at blu.org (Subject line is ignored).
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |