Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

debugger plugin: catch the inferior PID under gdb

<< < (6/6)

MortenMacFly:

--- Quote from: MortenMacFly on January 30, 2016, 09:55:17 pm ---Did you miss to provide some portions?

--- End quote ---
Maybe the Windows part should more look like this:

--- Code: (cpp) ---    // get a function pointer to DebugBreakProcess under windows (XP+)
    typedef HANDLE WINAPI CreateToolhelp32SnapshotFunc(DWORD dwFlags, DWORD th32ProcessID);
    static CreateToolhelp32SnapshotFunc* snapshotFunc = NULL;
    typedef BOOL WINAPI Process32FirstFunc(HANDLE hSnapshot, LPPROCESSENTRY32 lppe);
    static Process32FirstFunc* firstFunc = NULL;
    typedef BOOL WINAPI Process32NextFunc(HANDLE hSnapshot, LPPROCESSENTRY32 lppe);
    static Process32NextFunc* nextFunc = NULL;
    HMODULE kernel32DLL = LoadLibrary(TEXT("kernel32.dll"));
    if (kernel32DLL)
    {
        snapshotFunc = (CreateToolhelp32SnapshotFunc*) GetProcAddress(kernel32DLL, "CreateToolhelp32Snapshot");
        firstFunc    = (Process32FirstFunc*)           GetProcAddress(kernel32DLL, "Process32First");
        nextFunc     = (Process32NextFunc*)            GetProcAddress(kernel32DLL, "Process32Next");
    }
    if ( (NULL!=snapshotFunc) && (NULL!=firstFunc) && (NULL!=nextFunc) )
    {
        HANDLE snap = snapshotFunc(TH32CS_SNAPALL,0);
        if (snap!=INVALID_HANDLE_VALUE)
        {
            PROCESSENTRY32 lppe;
            lppe.dwSize = sizeof(PROCESSENTRY32);
            BOOL ok = firstFunc(snap, &lppe);
            while (ok == TRUE)
            {
                if (lppe.th32ParentProcessID == parent) // Have my Child...
                    children.push_back(lppe.th32ProcessID);
                lppe.dwSize = sizeof(PROCESSENTRY32);
                ok = nextFunc(snap, &lppe);
            }
            CloseHandle(snap);
        }
    }

--- End code ---

oBFusCATed:
I've not tested it on windows, yet.
And I think I have to turn it into a class that is owned by the debugger plugin, so it will be able to do the dll cleanup.

This is just a proof of concept if it solves the problem.

Huki:

--- Quote from: oBFusCATed on January 30, 2016, 07:05:38 pm ---For some reason on your systems the first thread doesn't have the same pid as the process.
--- End quote ---
In fact the main thread does have the same pid as the process, but it's not printed by gdb. Gdb only seems to print additionally created threads. As an example, this is a gdb log with thread info (note that there is no "New Thread" message for the main thread):

--- Code: ---[New Thread 0xb4b27b40 (LWP 3861)]
[Thread 0xb4b27b40 (LWP 3861) exited]
[New Thread 0xb4b27b40 (LWP 3862)]
[New Thread 0xb01feb40 (LWP 3863)]
^C
Program received signal SIGINT, Interrupt.
0xb7fdbbe8 in __kernel_vsyscall ()
(gdb) info threads
  Id   Target Id         Frame
  4    Thread 0xb01feb40 (LWP 3863) [...]
  3    Thread 0xb4b27b40 (LWP 3862) [...]
* 1    Thread 0xb5240780 (LWP 3857) [...]
(gdb) info program
Using the running image of child Thread 0xb5240780 (LWP 3857).

--- End code ---


--- Quote ---Can you check if the parent pid of the threads in your program is the same as the pid of the process?
--- End quote ---
Yes it is:

--- Code: ---~$ ps -L 3857
  PID   LWP TTY      STAT   TIME COMMAND
 3857  3857 pts/9    tl     0:00 [...]
 3857  3862 pts/9    tl     0:00 [...]
 3857  3863 pts/9    tl     0:00 [...]

--- End code ---

oBFusCATed:
Thanks. I'll make a proper patch that could be tested.

Navigation

[0] Message Index

[*] Previous page