By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
431,919 Members | 1,587 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 431,919 IT Pros & Developers. It's quick & easy.

can not acess memory at address ox0

P: n/a
my C program crashes due to segfault .
And on using gdb it shows message
"can not acess memory at address ox0"
what could be the possible problem.
Program is vary complecated so i can not simple debug using my own
debug statments.
and PC's value is 0x00000 which is no way helpful for backtracking the
problem.
Sp please guide me .

Regard,
Gogo

Apr 17 '06 #1
Share this Question
Share on Google+
4 Replies


P: n/a
gogo wrote:
my C program crashes due to segfault .
And on using gdb it shows message
"can not acess memory at address ox0"
what could be the possible problem. The problem is a bug. Perhaps that sounds vague, but so is
your question and problem.

Likely you are dereferencing a NULL pointer, which could
be the result of any of some thousand different problems.
Program is vary complecated so i can not simple debug using my own
debug statments.
and PC's value is 0x00000 which is no way helpful for backtracking the
problem.


Improve your debugging skills. Atleast try to get a backtrace from
'gdb', try to inspect which variable that has an unexpected value.
A backtrace might show the line of the source code where things
failed - that's always a nice start.

For further help, post the problematic code. If it isn't standard
C, ask in a news group for your platform.

Apr 17 '06 #2

P: n/a
Ico
gogo <yo*************@gmail.com> wrote:
my C program crashes due to segfault .
And on using gdb it shows message
"can not acess memory at address ox0"
what could be the possible problem.
I guess your program tries to access memory at address 0.
Program is vary complecated so i can not simple debug using my own
debug statments.
Given enough time and effort, this should always be possible.
and PC's value is 0x00000 which is no way helpful for backtracking the
problem.


There might be a simple way; run your program in a debugger, trigger the
problem and make a stack backtrace. If you are lucky, the faulty code
has not completely messed up the stack, and the debugger can give you an
indication where the problem occured.

--
:wq
^X^Cy^K^X^C^C^C^C
Apr 17 '06 #3

P: n/a
I've already tried backtrace(bt) and where options of gdb for my
problem .
but for every command gdb shows message "can not access memory at 0x0"
..
And I'm not sure that this problem is about NULL pointer dereferancing
,because i triedNULL pointer dereferancing in saparate sample
application .
but inthat can PC(program counters) value and bt of gdb both were
useful for tracing exact instruction in which NULL pointer
dereferancing was done .
So only basic knowlege of debuging (which i alredy have :) ) will not
do.I need some expert's Help
What is significance of all Other Register Vlaues printed along with PC
after program crash??

I'm using gdb ported for arm-linux

Apr 17 '06 #4

P: n/a
gogo wrote:
I've already tried backtrace(bt) and where options of gdb for my
problem .
but for every command gdb shows message "can not access memory at 0x0"
.
And I'm not sure that this problem is about NULL pointer dereferancing
,because i triedNULL pointer dereferancing in saparate sample
application .
but inthat can PC(program counters) value and bt of gdb both were
useful for tracing exact instruction in which NULL pointer
dereferancing was done .
So only basic knowlege of debuging (which i alredy have :) ) will not
do.I need some expert's Help
What is significance of all Other Register Vlaues printed along with PC
after program crash??

I'm using gdb ported for arm-linux


Did you compile with debugging support ?

It is ofcourse possible your program has a nasty enough bug it
makes debugging just not possible.(e.g. it overwrites vital parts of a
stack frame).

At this point, unless you show some standard C code, your problem is
off topic here.

Apr 17 '06 #5

This discussion thread is closed

Replies have been disabled for this discussion.