"Cannot access memory at address 0x175f80"

"Cannot access memory at address 0x175f80"

[Andrew Greenlaw]

  Hi.  I'm debugging a C++ tool (called apple) that's loaded as a 
dynamic library into a C - or C++ program (called orange) .  Apple is 
compiled with g++ 3.3.1, binutils 2.14, and debugging symbols are 
enabled.  Orange is a big unknown (meaning:  I don't know how it was 
compiled) and it has no debugging symbols.  The gdb version is 5.3

    Here are the flags used to compile Apple:
# -gdwarf-2 -g3 used to enable stepping through macro execution under 
gdb 5.3  The explanation's under gdb 5.3 release notes.
    Compile:g++  -std=c++98 -Wall -DLINUX -gdwarf-2 -g3      -D__USE_GNU 
-D_GNU_SOURCE -fPIC file_name.cpp


    Link:
    g++ -shared $(LIBS) $(OBJSCHEF)  $(PLIOBJSVCS_PLI) 
InterfaceObjectVCS_PLI.o -o $@    -lc   gdwarf-2 -g3 -fPIC
g++  -MD -std=c++98  -shared -lc -gdwarf-2 -g3  -fPIC <object files>  -o 
libapple.so   

    When I go to debug apple, I run "gdb <program name>", then use the 
"add-symbol-file <apple's path & filename> -readnow" gdb comman to load 
the symbols from apple.  From there, I can set breakpoints in C++ class 
methods, no problem.  But, there is 1 function (so, non-OO code), where 
if I try to set a breakpoint, I get the following:

    (gdb) break nc_signal_raised
Cannot access memory at address 0x175f80

    If I do an "nm" on the library, I get:
    00175f80 T nc_signal_raised

    Indicating that the address read by gdb is correct.

    On a related, but less important note, when use ddd to debug & go to 
a source file, I always get:  "<src_file_name>" is at address 0x10f5f0 
<part_of_src_file_name> but contains no code.

    And yet I can set breakpoints or step through the code.  What's 
going on?

    Any help you can offer will be appreciated.  I've been working on 
this for 2 weeks, read every posting or piece of documentation I can 
find.  I'm at my wits' end!
   

-- 
          Andrew Greenlaw
****

Re: "Cannot access memory at address 0x175f80"

[Daniel Jacobowitz]

On Fri, Sep 26, 2003 at 01:40:16PM -0400, Andrew Greenlaw wrote:
>  Hi.  I'm debugging a C++ tool (called apple) that's loaded as a 
> dynamic library into a C - or C++ program (called orange) .  Apple is 
> compiled with g++ 3.3.1, binutils 2.14, and debugging symbols are 
> enabled.  Orange is a big unknown (meaning:  I don't know how it was 
> compiled) and it has no debugging symbols.  The gdb version is 5.3
> 
>    Here are the flags used to compile Apple:
> # -gdwarf-2 -g3 used to enable stepping through macro execution under 
> gdb 5.3  The explanation's under gdb 5.3 release notes.
>    Compile:g++  -std=c++98 -Wall -DLINUX -gdwarf-2 -g3      -D__USE_GNU 
> -D_GNU_SOURCE -fPIC file_name.cpp
> 
> 
>    Link:
>    g++ -shared $(LIBS) $(OBJSCHEF)  $(PLIOBJSVCS_PLI) 
> InterfaceObjectVCS_PLI.o -o $@    -lc   gdwarf-2 -g3 -fPIC
> g++  -MD -std=c++98  -shared -lc -gdwarf-2 -g3  -fPIC <object files>  -o 
> libapple.so   
> 
>    When I go to debug apple, I run "gdb <program name>", then use the 
> "add-symbol-file <apple's path & filename> -readnow" gdb comman to load 
> the symbols from apple.  From there, I can set breakpoints in C++ class 
> methods, no problem.  But, there is 1 function (so, non-OO code), where 
> if I try to set a breakpoint, I get the following:
> 
>    (gdb) break nc_signal_raised
> Cannot access memory at address 0x175f80
> 
>    If I do an "nm" on the library, I get:
>    00175f80 T nc_signal_raised
> 
>    Indicating that the address read by gdb is correct.

Unlikely, since the library is not loaded at a base address of 0.

>    On a related, but less important note, when use ddd to debug & go to 
> a source file, I always get:  "<src_file_name>" is at address 0x10f5f0 
> <part_of_src_file_name> but contains no code.
> 
>    And yet I can set breakpoints or step through the code.  What's 
> going on?
> 
>    Any help you can offer will be appreciated.  I've been working on 
> this for 2 weeks, read every posting or piece of documentation I can 
> find.  I'm at my wits' end!

Why are you using add-symbol-file?  Is the loader not done as a dlopen,
i.e. are you dealing with something that has its own dynamic loader? 
If it's dlopen'd, gdb should automatically handle it.

It seems unlikely that add-symbol-file without specifying a text offset
is right, too.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: "Cannot access memory at address 0x175f80"

[Daniel Jacobowitz]

On Fri, Sep 26, 2003 at 02:16:53PM -0400, Andrew Greenlaw wrote:
>    I was specifying add-symbol-file, because when I start "orange", 
> none of the symbols from "apple" are accessible.  In DDD, the source 
> code for Apple's files don't even appear in the "open source" menu.  The 
> only 2 ways to make those files appear are 1) to run the program once, 
> then set breakpoints, then re-run, or 2) use the add-symbol-file 
> command.  I admit I wasn't using it in an informed manner, but it worked 
> for the other symbols.
> 
>    I tried a little experiment:  I started gdb, used the 
> add-symbol-file command, then entered "break nc_signal_raised".  It said 
> "Cannot access memory at address 0x175f9c".  I then exited gdb, started 
> over, and this time, instead of add-symbol-file, ran the program.  when 
> the program exitted, I typed "break nc_signal_raised", It said 
> "Breakpoint 1 at 0x40fb2f9f: file /sopt/ldv-dev/tools/src/main.cc, line 
> 8.".  So that was part of the problem.
> 
>    Now the bad news.  If I try to re-run, this particular breakpoint 
> can't be inserted.  After that encouraging message above, I hit the 
> "run" button in ddd, and got:
> 
> (gdb) run snap1
> (no debugging symbols found)...Error in re-setting breakpoint 1:
> Function "nc_signal_raised" not defined.
> Error in re-setting breakpoint 1:
> Function "nc_signal_raised" not defined.
> Error in re-setting breakpoint 1:
> Function "nc_signal_raised" not defined.
> Error in re-setting breakpoint 1:
> Function "nc_signal_raised" not defined.
> Error in re-setting breakpoint 1:
> Function "nc_signal_raised" not defined.
> Error in re-setting breakpoint 1:
> Function "nc_signal_raised" not defined.
> Error in re-setting breakpoint 1:
> Function "nc_signal_raised" not defined.
> Error in re-setting breakpoint 1:
> Function "nc_signal_raised" not defined.
> Error in re-setting breakpoint 1:
> Function "nc_signal_raised" not defined.
> ncsim: 05.00-s005: (c) Copyright 1995-2003 Cadence Design Systems, Inc.
> ncsim: *W,DLNOHV: Unable to find an 'hdl.var' file to load in.
> Error in re-setting breakpoint 1:
> Function "nc_signal_raised" not defined.
> Error in re-setting breakpoint 1:
> Function "nc_signal_raised" not defined.
> Error in re-setting breakpoint 1:
> Function "nc_signal_raised" not defined.
> Error in re-setting breakpoint 1:
> Function "nc_signal_raised" not defined.
> Error in re-setting breakpoint 1:
> Function "nc_signal_raised" not defined.
> Error in re-setting breakpoint 1:
> Function "nc_signal_raised" not defined.
> 
>    Any Ideas?

Sure, it's noisy, but does the breakpoint eventually get defined?

If not, set stop-on-solib-events to 1 and then hit continue until info
shared reports that module loaded.  Then enable the breakpoint.

> 
> Daniel Jacobowitz wrote:
> 
> >On Fri, Sep 26, 2003 at 01:40:16PM -0400, Andrew Greenlaw wrote:
> > 
> >
> >>Hi.  I'm debugging a C++ tool (called apple) that's loaded as a 
> >>dynamic library into a C - or C++ program (called orange) .  Apple is 
> >>compiled with g++ 3.3.1, binutils 2.14, and debugging symbols are 
> >>enabled.  Orange is a big unknown (meaning:  I don't know how it was 
> >>compiled) and it has no debugging symbols.  The gdb version is 5.3
> >>
> >>  Here are the flags used to compile Apple:
> >># -gdwarf-2 -g3 used to enable stepping through macro execution under 
> >>gdb 5.3  The explanation's under gdb 5.3 release notes.
> >>  Compile:g++  -std=c++98 -Wall -DLINUX -gdwarf-2 -g3      -D__USE_GNU 
> >>-D_GNU_SOURCE -fPIC file_name.cpp
> >>
> >>
> >>  Link:
> >>  g++ -shared $(LIBS) $(OBJSCHEF)  $(PLIOBJSVCS_PLI) 
> >>InterfaceObjectVCS_PLI.o -o $@    -lc   gdwarf-2 -g3 -fPIC
> >>g++  -MD -std=c++98  -shared -lc -gdwarf-2 -g3  -fPIC <object files>  -o 
> >>libapple.so   
> >>
> >>  When I go to debug apple, I run "gdb <program name>", then use the 
> >>"add-symbol-file <apple's path & filename> -readnow" gdb comman to load 
> >>the symbols from apple.  From there, I can set breakpoints in C++ class 
> >>methods, no problem.  But, there is 1 function (so, non-OO code), where 
> >>if I try to set a breakpoint, I get the following:
> >>
> >>  (gdb) break nc_signal_raised
> >>Cannot access memory at address 0x175f80
> >>
> >>  If I do an "nm" on the library, I get:
> >>  00175f80 T nc_signal_raised
> >>
> >>  Indicating that the address read by gdb is correct.
> >>   
> >>
> >
> >Unlikely, since the library is not loaded at a base address of 0.
> >
> > 
> >
> >>  On a related, but less important note, when use ddd to debug & go to 
> >>a source file, I always get:  "<src_file_name>" is at address 0x10f5f0 
> >><part_of_src_file_name> but contains no code.
> >>
> >>  And yet I can set breakpoints or step through the code.  What's 
> >>going on?
> >>
> >>  Any help you can offer will be appreciated.  I've been working on 
> >>this for 2 weeks, read every posting or piece of documentation I can 
> >>find.  I'm at my wits' end!
> >>   
> >>
> >
> >Why are you using add-symbol-file?  Is the loader not done as a dlopen,
> >i.e. are you dealing with something that has its own dynamic loader? 
> >If it's dlopen'd, gdb should automatically handle it.
> >
> >It seems unlikely that add-symbol-file without specifying a text offset
> >is right, too.
> >
> > 
> >
> 
> -- 
>          Andrew Greenlaw, Advanced Verification Group
>          Agere Systems of Ottawa, ON.  Intranet page:  
>          http://ottawa/~andrewg/
>          E-mail:  andrewg@agere.com, Phone: (613)768-8738, Fax:  
>          (768)768-8710
> ****
>     "A mathematician is a device for turning coffee into theorems."
>     - Paul Erdos
> ****
> 
> 
> 
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: "Cannot access memory at address 0x175f80"

[Andrew Greenlaw]

    I was specifying add-symbol-file, because when I start "orange", 
none of the symbols from "apple" are accessible.  In DDD, the source 
code for Apple's files don't even appear in the "open source" menu.  The 
only 2 ways to make those files appear are 1) to run the program once, 
then set breakpoints, then re-run, or 2) use the add-symbol-file 
command.  I admit I wasn't using it in an informed manner, but it worked 
for the other symbols.

    I tried a little experiment:  I started gdb, used the 
add-symbol-file command, then entered "break nc_signal_raised".  It said 
"Cannot access memory at address 0x175f9c".  I then exited gdb, started 
over, and this time, instead of add-symbol-file, ran the program.  when 
the program exitted, I typed "break nc_signal_raised", It said 
"Breakpoint 1 at 0x40fb2f9f: file /sopt/ldv-dev/tools/src/main.cc, line 
8.".  So that was part of the problem.

    Now the bad news.  If I try to re-run, this particular breakpoint 
can't be inserted.  After that encouraging message above, I hit the 
"run" button in ddd, and got:

(gdb) run snap1
(no debugging symbols found)...Error in re-setting breakpoint 1:
Function "nc_signal_raised" not defined.
Error in re-setting breakpoint 1:
Function "nc_signal_raised" not defined.
Error in re-setting breakpoint 1:
Function "nc_signal_raised" not defined.
Error in re-setting breakpoint 1:
Function "nc_signal_raised" not defined.
Error in re-setting breakpoint 1:
Function "nc_signal_raised" not defined.
Error in re-setting breakpoint 1:
Function "nc_signal_raised" not defined.
Error in re-setting breakpoint 1:
Function "nc_signal_raised" not defined.
Error in re-setting breakpoint 1:
Function "nc_signal_raised" not defined.
Error in re-setting breakpoint 1:
Function "nc_signal_raised" not defined.
ncsim: 05.00-s005: (c) Copyright 1995-2003 Cadence Design Systems, Inc.
ncsim: *W,DLNOHV: Unable to find an 'hdl.var' file to load in.
Error in re-setting breakpoint 1:
Function "nc_signal_raised" not defined.
Error in re-setting breakpoint 1:
Function "nc_signal_raised" not defined.
Error in re-setting breakpoint 1:
Function "nc_signal_raised" not defined.
Error in re-setting breakpoint 1:
Function "nc_signal_raised" not defined.
Error in re-setting breakpoint 1:
Function "nc_signal_raised" not defined.
Error in re-setting breakpoint 1:
Function "nc_signal_raised" not defined.

    Any Ideas?

Daniel Jacobowitz wrote:

>On Fri, Sep 26, 2003 at 01:40:16PM -0400, Andrew Greenlaw wrote:
>  
>
>> Hi.  I'm debugging a C++ tool (called apple) that's loaded as a 
>>dynamic library into a C - or C++ program (called orange) .  Apple is 
>>compiled with g++ 3.3.1, binutils 2.14, and debugging symbols are 
>>enabled.  Orange is a big unknown (meaning:  I don't know how it was 
>>compiled) and it has no debugging symbols.  The gdb version is 5.3
>>
>>   Here are the flags used to compile Apple:
>># -gdwarf-2 -g3 used to enable stepping through macro execution under 
>>gdb 5.3  The explanation's under gdb 5.3 release notes.
>>   Compile:g++  -std=c++98 -Wall -DLINUX -gdwarf-2 -g3      -D__USE_GNU 
>>-D_GNU_SOURCE -fPIC file_name.cpp
>>
>>
>>   Link:
>>   g++ -shared $(LIBS) $(OBJSCHEF)  $(PLIOBJSVCS_PLI) 
>>InterfaceObjectVCS_PLI.o -o $@    -lc   gdwarf-2 -g3 -fPIC
>>g++  -MD -std=c++98  -shared -lc -gdwarf-2 -g3  -fPIC <object files>  -o 
>>libapple.so   
>>
>>   When I go to debug apple, I run "gdb <program name>", then use the 
>>"add-symbol-file <apple's path & filename> -readnow" gdb comman to load 
>>the symbols from apple.  From there, I can set breakpoints in C++ class 
>>methods, no problem.  But, there is 1 function (so, non-OO code), where 
>>if I try to set a breakpoint, I get the following:
>>
>>   (gdb) break nc_signal_raised
>>Cannot access memory at address 0x175f80
>>
>>   If I do an "nm" on the library, I get:
>>   00175f80 T nc_signal_raised
>>
>>   Indicating that the address read by gdb is correct.
>>    
>>
>
>Unlikely, since the library is not loaded at a base address of 0.
>
>  
>
>>   On a related, but less important note, when use ddd to debug & go to 
>>a source file, I always get:  "<src_file_name>" is at address 0x10f5f0 
>><part_of_src_file_name> but contains no code.
>>
>>   And yet I can set breakpoints or step through the code.  What's 
>>going on?
>>
>>   Any help you can offer will be appreciated.  I've been working on 
>>this for 2 weeks, read every posting or piece of documentation I can 
>>find.  I'm at my wits' end!
>>    
>>
>
>Why are you using add-symbol-file?  Is the loader not done as a dlopen,
>i.e. are you dealing with something that has its own dynamic loader? 
>If it's dlopen'd, gdb should automatically handle it.
>
>It seems unlikely that add-symbol-file without specifying a text offset
>is right, too.
>
>  
>

-- 
          Andrew Greenlaw, Advanced Verification Group
          Agere Systems of Ottawa, ON.  Intranet page:  http://ottawa/~andrewg/
          E-mail:  andrewg@agere.com, Phone: (613)768-8738, Fax:  (768)768-8710
****
     "A mathematician is a device for turning coffee into theorems."
     - Paul Erdos
****