ansaurus

Question

Answer 1

+1 A:

What I can see immediately from looking at your output is that:

a) The version of GDB you are using is outdated by a year.

b) None of the output you provided is very useful; you need to post a backtrace.

Now, the last entry in a backtrace, or rather, where the program actually stopped (libXm in this case), is almost never the actual cause of the problem. Assuming that libXm isn't at fault, you really need a proper backtrace to see the last point of execution which involved the code YOU wrote; this is a more likely source of the problem.

One more thing; learn to use GDB. It's a necessity if you're ever going to write a program longer than a few lines.

Seisatsu 2010-02-19 05:43:17

I never realized that GDB was perishable.

bk1e 2010-02-19 06:57:26

Thanks for the tips... Just FYI, this isn't code that I wrote, its code moved from a Forte c compiler to GNAT.. I am new to the whole GNAT world... Trying to figure out how to backtrace now..

Grasper 2010-02-19 13:48:00

Outdated by a year? We need to use `GNU gdb 6.3.50-20050815 (Apple version gdb-1461)`!

KennyTM 2010-02-20 06:48:14

"It's a necessity if you're ever going to write a program longer than a few lines" - a lot of us manage to write a lot more code than that without using a debugger of any sort - in general, the debugger should be the last resort, not the first.

anon 2010-02-22 17:29:52

Answer 2

+1 A:

Your problem is in your memset.

Arg      args[MAX_ARGS];
...
memset(&(args), 0, sizeof(Arg)*MAX_ARGS); n_args = 0;

Here, you are using &(args) where you should be using args or &args[0]. args is a pointer to the start of the array, and &(args) is a pointer-to-pointer. When you try to memset &(args), you are attempting to write a (potentially) large swath of zeroes over a memory range you shouldn't be writing to. At some point, that command tried to write into a memory range it wasn't supposed to touch, and the system killed it.

bta 2010-02-20 01:16:16

Grasper 2010-02-20 03:44:23

Nathan Kidd 2010-02-20 06:47:00

AndreyT 2010-02-25 07:33:41

Answer 3

+4 A:

Your crash is happening inside libXm. Either your heap has been corrupted beforehand, or you are passing in bad data (or, much less likely, there's a bug in libXm and/or other system libs). The args stuff looks like it is okay (though your memset is a bit non-standard).

To test for heap corruption use Valgrind, but I'm not sure it's available on Solaris. You could build your package on Linux and see if you get the same crash there.

(If you switch to linux you can install the debug symbols + source for libXm easily, to figure out where the data may be going wrong.)

For the 3rd (unlikely) possibility, check you're at the latest patch level.

Nathan Kidd 2010-02-20 06:45:34

The Sun Studio dbx on Solaris has memory checking facilities built in - not as many as valgrind, but much better than nothing. See http://stackoverflow.com/questions/1881343/locate-bad-memory-access-on-solaris

alanc 2010-02-20 06:57:20

I added dbx output

Grasper 2010-02-21 16:51:17

@Grasper, you enabled "check -all" *after* the segv. If you're looking for heap corruption you must break on main, and enable it *before* the segv. That said, dbx isn't as thorough as Valgrind so it is possible it still doesn't detect a real problem.

Nathan Kidd 2010-02-22 17:32:10

Answer 4

+4 A:

Given that dbx said "Attempting to read 4 bytes through NULL pointer", and that the error was reported on the line with the function call and not inside the XmCreateMainWindow function, I assume the problem has something to do with the statement win->name. This is the only place on this line of C where you would be reading from a pointer before the function is actually called (it will read a copy of the data stored in win->name and pass the copy to the function).

Try inserting the following on the line immediately above the call to XmCreateMainWindow

assert(win != NULL);

You will need to #include <assert.h> if it isn't already. This should verify that win isn't a NULL pointer when the function is called. For the sake of being thorough, you may want to add a similar line for shell as well.

bta 2010-02-23 17:04:47

Answer 5

+1 A:

Replace memset with a function that sets the different args manually. memset should only be used on byte arrays because with any other type 0 may not mean what you think it means.

Kevin H 2010-02-24 22:53:46

Answer 6

+1 A:

N 1.1 2010-02-24 23:13:29

IMHO "gdb output" is absolutely readable for any programmer worth his salt.

ggiroux 2010-02-26 01:08:58

I specifically wrote 'can be difficult' :). And yeah, its important.

N 1.1 2010-02-26 01:39:56

Answer 7

+1 A:

You're passing NULL as the first argument to XmCreateMainWindow(parent, ...) while most samples found on google seem to pass a non-NULL Widget coming from XtVaAppInitialize() there, are you sure that you shouldn't be doing that too?

failing that, in gdb, put a breakpoint on the line 180 win->main_window = XmCreateMainWindow(shell, win->name, args, n_args);

and execute the 'p *win' command there, and the output should be enlightening. Probably a member of the "win" structure that shall be initialized is null or garbage, and that should get you going.

ggiroux 2010-02-25 06:15:48

Can you look at the updated output I added to my question?

Grasper 2010-02-26 21:54:13

Answer 8

+1 A:

I would drop the memset function calls. All of the examples that I have seen just reset the argument count back to 0.

I am not sure if it is available to you, but DTrace was built for this sort of thing. Here is a blog that talks about it. http://blogs.sun.com/observatory/entry/d_script_archeology

Jacob

TheJacobTaylor 2010-02-25 07:19:21

Answer 9

+1 A:

This may be a long shot, but have you tried "disassemble" on those memory addresses in the backtrace? If you have some basic understanding of assembly, you might be able to discern something out of place that way. As several people mentioned, you're likely accessing a bad pointer somewhere. Sometimes the assembly will reveal which pointer's address is something that doesn't seem "right." It's something that's pointed me in the right direction in the past.

Mutmansky 2010-02-25 22:16:22

ansaurus

tags:

views:

answers:

Troubleshooting segmentation Fault

related questions