DeeJayBee

Forum Replies Created

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • in reply to: Memory change breakpoints not being hit #25198
    DeeJayBee
    Participant

    Ah ok; I tried running instead of stepping and it seems that the breakpoints are indeed being hit; so it is clearly an issue with stepping that causes this.

    Furthermore, I tried this on a separate machine, with the GDB ‘show version’ command outputting

    (gdb) show version
    GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1

    …whilst the problematic RHEL box giving

    (gdb) show version
    GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-94.el7

    So one further possibility would be to try and update this version to a later one to see if that resolves it.  But in the meantime, in this small piece of code at least, I know how to work around it.

    Thanks for your timely support and responses!

    in reply to: Memory change breakpoints not being hit #25189
    DeeJayBee
    Participant

    Thank you!

    The code I am running is

    int main(int argc, char** argv)
    {
    int* p = new int;
    p = 0;
    
    return 0;
    }

    I have determined via the watch window (expression &p) that the address of p is 0x00007fffffffe9c8, and on each run it appears to be the same (I verify this of course!). I add a data breakpoint on this address (4 bytes).

    If I enable the breakpoint, THEN step into the code, the breakpoint is hit several times (as in, the message box appears stating so!). I presume this is because the C runtime is manipulating memory as part of the course of starting my program…this shows that the functionality is working to some degree hence!

    If on the other hand I step into the code, AND THEN enable the breakpoint, after verifying that &p is still the same (0x00007fffffffe9c8 here), then stepping over my two lines of code that adjust p, the breakpoint is not fired.

    I ran “x 0x00007fffffffe9c8” in the GDB window as requested, all times the output was

    x 0x00007fffffffe9c8
    &"x 0x00007fffffffe9c8\n"
    0x7fffffffe9c8: add BYTE PTR [rax],al
    OK

    When I run past the end of main(), and hit F5 to continue debugging, I do get the breakpoint hit, but the callstack at this stage is

    > libc.so.6!__run_exit_handlers 
    libc.so.6!exit 
    libc.so.6!__libc_start_main 
    _start

    …which is clearly not in my code. I expect a breakpoint to be triggered on both the new() call and the reset to 0.

    I have attached my log. Hoping this can be of use!

    Can you replicate this problem on your machine?

    in reply to: Change font in SSH and GDB window #25181
    DeeJayBee
    Participant

    That did it, thanks!

    in reply to: Change font in SSH and GDB window #25179
    DeeJayBee
    Participant

    Thanls very much that has reduced the font size!

    Can you tell me how to configure the background colour of the window please; on one machine it is black, yet on another it is white.  I cannot find anything in the settings to control this; I thought it would be the “output window” background colour in the general VS “fonts and colours” settings, but this is set to the same (custom) colour on both these machines…

    in reply to: Change font in SSH and GDB window #25174
    DeeJayBee
    Participant

    Hi, I was about to create a new thread for this very same problem; I have the very latest (June 2019) build and this is still a problem unless I am doing something wrong; please see the screenshot below.  Thanks!

    (EDIT: the “VisualGDB Remote Console” window displays the correct font type/size however!)

    • This reply was modified 4 years, 10 months ago by DeeJayBee.
    Attachments:
    You must be logged in to view attached files.
    in reply to: Clang intellisense limitations #25119
    DeeJayBee
    Participant

    Thank you, that is truly awesome!  The first time I tried ALT+click (I have configured the alt key not CTRL key) I got a VS exception dialog, but have not done since.  I will continue to play with it and report back if it keeps happening again!

    Thanks greatly once again!

    in reply to: Clang intellisense limitations #25111
    DeeJayBee
    Participant

    Thanks!

    Shame about the ctrl-click, that is almost a deal breaker for me for using the clang engine.  Is there no way at all it could be implemented?  If you can control the combo-box that appears via autocomplete, you can surely change the cursor to a hand/underline the current type when CTRL (or whatever the user has configured, ALT in my case) is pressed, then fire the same handler that the “Go to” button invokes?

    And regarding the templates, it seems that (in my case at least) I need to invoke the auto complete manually in order to get the combo box that lists the auto complete types, then press tab to ‘invoke’ the auto selected one.  That is, when I start typing ‘for’ or ‘class’ (or in fact any global symbol name) the combo does not automatically appear, I have to press the keystroke bound to the menu command “Edit->Intellisense->Complete word” to get it to appear, where I can then tab to insert the template.

    In normal intellisense, as soon as I start typing, the combo appears.

    Note that there does not appear to be a problem auto completing object members in clang intellisense; if I make a class declaration with a public member variable or function, then create a static instance, as soon as I press the ‘.’ key, the combo listing members appears.

    Is this by design?

    • This reply was modified 4 years, 10 months ago by DeeJayBee.
Viewing 7 posts - 1 through 7 (of 7 total)