[Bug 10249] New: Battlefield2/SafeDisc 4. x and Punkbuster services cause lockup: child processes debugging misconception
wine-bugs at winehq.org
wine-bugs at winehq.org
Tue Oct 30 19:35:16 CDT 2007
http://bugs.winehq.org/show_bug.cgi?id=10249
Summary: Battlefield2/SafeDisc 4.x and Punkbuster services cause
lockup: child processes debugging misconception
Product: Wine
Version: CVS/GIT
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: major
Priority: P2
Component: wine-kernel
AssignedTo: wine-bugs at winehq.org
ReportedBy: focht at gmx.net
Created an attachment (id=8876)
--> (http://bugs.winehq.org/attachment.cgi?id=8876)
WINEDEBUG=-all,+server,+tid,+loaddll,+seh wine ./BF2.exe +fullscreen 0 +szx 800
+szy 600 &>/tmp/debug_pipe
Hello,
while testing some PunkBuster stuff on popular games, I came across Battlefield
2 which employs SafeDisc 4.x
It seems there is a problem with debuggers in chained child processes.
Consider following scenario:
--- snip process list ---
pid threads parent executable (all id:s are in hex)
0000001b 1 00000008 'PnkBstrA.exe'
0000000c 2 00000008 'explorer.exe'
0000000a 2 00000008 '~e5.0001'
00000008 4 00000000 'BF2.exe'
--- snip process list ---
--- snip thread list ---
process tid prio (all id:s are in hex)
0000001b
0000001c 0
0000000c
00000010 0
0000000d 0
0000000a
00000012 0
0000000b 0
00000008
0000001a 1
00000014 15
00000013 0
00000009 0
--- snip thread list ---
"BF2.exe" = parent (game)
"~e5.0001" = 1st child = SafeDisc 4.x process = "debugger"
"PnkBstrA.exe" = 2nd child = PunkBuster Update Service
The 1st child acts as debugger for the parent "BF2.exe" and receives all debug
events (process, thread creation, dll load/unload...)
There are lots of breakpoint events triggered from parent.
This is part of SafeDisc 4.x and used for on-the-fly decryption of code
sections (child decrypts code of father).
When PunkBuster is initialized (loading of pbcl = client, pbag = agent), the
following services should get started: PnkBstrA.exe, PnkBstrB.exe and finally
the kmode driver PnkBstrK.exe
The service process "PnkBstrA.exe" is started from main process "BF2.exe"
(which is a debuggee itself).
No debug flags (DEBUG_PROCESS | DEBUG_ONLY_THIS_PROCESS) are specified in
process creation flags.
The debugger (child of parent, receives the process creation event) does not
make debugger_attach() to the newly created child process.
The child process seems to inherit the state of being a "debuggee": wine server
-> new_process -> set_process_debugger( process, parent->debugger );
The parent got its process->debugger from debugger_attach().
This leads to a problem in child process startup code:
"dlls/kernel32/process.c:start_process()" checks the PEB->BeingDebugged field
and if set, a system breakpoint is encountered before the entry code is called.
This breakpoint results in debug event - seen by debugger.
Unfortunately this event is _not_ expected by debugger because it didn't expect
another debuggee (child) to be created.
Ok, long story short solution: If you debug a process by attaching to an
already created process, you _must_ treat default debugging flags as if the
process has been created with DEBUG_ONLY_THIS_PROCESS, meaning that all childs
created by debuggee will NOT automagically become debuggees.
Short and (hopefully) acceptable patch snippet:
--- snip ---
diff --git a/server/debugger.c b/server/debugger.c
index a64a17a..c59f3a0 100644
--- a/server/debugger.c
+++ b/server/debugger.c
@@ -444,6 +444,7 @@ static int debugger_attach( struct process *process, struct
thread *debugger )
resume_process( process );
return 0;
}
+ process->create_flags |= DEBUG_ONLY_THIS_PROCESS;
return 1;
error:
--- snip ---
And yes, the patch (snippet) works as intended (tm) ;-)
Attached for sake of completeness is relevant server trace.
Search for "001c:trace:seh:raise_exception code=80000003 flags=0
addr=0x7b870ed8 " to the point where the entry system breakpoint is triggered.
Regards
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
More information about the wine-bugs
mailing list