Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 352415 - Spurious "compilation failed" errors
Summary: Spurious "compilation failed" errors
Status: NEW
Alias: None
Product: CDT
Classification: Tools
Component: cdt-core (show other bugs)
Version: 8.0   Edit
Hardware: PC Windows 7
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact: Jonah Graham CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-19 04:35 EDT by Samuel DEVULDER CLA
Modified: 2020-09-04 15:18 EDT (History)
0 users

See Also:


Attachments
A patch that adds a critical section and collects the exit status before clearing the pid. (2.12 KB, patch)
2011-07-19 04:39 EDT, Samuel DEVULDER CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Samuel DEVULDER CLA 2011-07-19 04:35:32 EDT
As described in http://www.eclipse.org/forums/index.php/t/210649/, I get false "compilation failed" errors. The reason seems to be related the fact that in Java_org_eclipse_cdt_utils_spawner_Spawner_waitFor:
1) pCurProcInfo->pid isn't protected from changes by other thread (waitProcTermination)
2) Java might be delayed and call spawner.waitPid(pid) right after the process has already been terminated and pCurProcInfo->pid cleared.

See the forum to view the details.
Comment 1 Samuel DEVULDER CLA 2011-07-19 04:39:08 EDT
Created attachment 199882 [details]
A patch that adds a critical section and collects the exit status before clearing the pid.

Details: 

This patch uses a critical section to get the pid and store it in local variable to prevent concurrent access from waitForTermination()'s thread. 

If waitForTermination()'s thread gets executed before java calls spawner.waitFor(pid), the exit code is collected and stored in the pCurProcInfo structure and the PID is cleared. Therefore, when waitFor() is later called and pid is cleared, the exit_code isn't obtained from the OS (the process is terminated anyway), but directly from the pCurProcInfo structure.

Using this patch I didn't get any more spurious compilation problems after about 24hours of cumulative compilation time.