Concurrency problems in fn2hash and other tools #267
Comments
|
Similar results on another executable: 2473.32372s OPTI[INFO ]: Writing serialized data took 382.011 seconds.
2478.50494s OPTI[INFO ]: Partitioned 2527920 bytes, 739384 instructions, 139875 basic blocks, 9361 data blocks and 12233 functions.
2484.35401s OOAN[WARN ]: No fallthru edge for call at 0x00498CFE
2484.45160s OOAN[WARN ]: Successor 0x004E925A of 4E9255: add fs:[ecx+0], ah not found.
2484.84855s OOAN[WARN ]: Successor 0x0065306C of 653064: imul si, [eax+ebp*2+0x73], 0x6740 not found.
2484.84864s OOAN[WARN ]: Successor 0x00653074 of 65306D: imul esp, [esi+0x66], 0x72657473 not found.
2484.84871s OOAN[WARN ]: Successor 0x0065307D of 65307C: outsd not found.
2484.84877s OOAN[WARN ]: Successor 0x006530A2 of 65309F: movq mm4, [esi] not found.
2484.84884s OOAN[WARN ]: Successor 0x006530EE of 6530EB: add [eax], 0 not found.
2486.85903s OOAN[ERROR]: Unable to find fallthru edge for call at 0x00498CFE
2492.35198s APID[WARN ]: API database has no data for DLL: DDRAW
2492.35205s OOAN[WARN ]: No stack delta information for: DDRAW.dll:DirectDrawCreate
2492.35209s OOAN[WARN ]: No stack delta information for: DDRAW.dll:DirectDrawEnumerateA
2492.35224s APID[WARN ]: API database has no data for DLL: DINPUT
2492.35229s OOAN[WARN ]: No stack delta information for: DINPUT.dll:DirectInputCreateA
2492.35241s APID[WARN ]: API database has no data for DLL: DSOUND
2492.35246s OOAN[WARN ]: No stack delta information for: DSOUND.dll:1
MATCHER parse error: line 1: syntax error at SgAsmMemoryReferenceExpression
MATCHER parse error: line 1: syntax error at $EXP
MATCHER parse error: line 1: syntax error at
ERROR 1: Lexical error! : <>
MATCHER parse error: line 1: syntax error at SgAsmMemoryReferenceExpression
ERROR 1: Lexical error! : <>
2508.74145s [INFO ]: Pharos main error: (boost::wrapexcept<boost::lock_error>) boost: mutex lock failed in pthread_mutex_lock: Invalid argument |
|
Well, this is a new one. Are you using the docker container or your own build? What command line are you using? And does it happen on every executable, or just some? |
|
In @Trass3r , may I ask what compiler (type and version) you used to compile ROSE? We should probably not rely on ROSE's |
|
This is an untested modification to ROSE that might solve the problem. I'd want to recreate the problem to test it before submitting it upstream. 2 files changed, 4 insertions(+), 14 deletions(-)
src/midend/astMatching/AstTerm.C | 6 +-----
src/midend/astMatching/MatchOperation.C | 12 +++---------
modified src/midend/astMatching/AstTerm.C
@@ -19,11 +19,7 @@ std::string AstTerm::nodeTypeName(SgNode* node) {
if(node==0) {
return "null";
} else {
- std::string tid=typeid(*node).name();
- int j=0;
- while(tid[j]>='0' && tid[j]<='9') j++;
- tid=tid.substr(j,tid.size()-j);
- return tid;
+ return node->class_name();
}
}
modified src/midend/astMatching/MatchOperation.C
@@ -132,13 +132,7 @@ MatchOpVariableAssignment::performOperation(MatchStatus& status, RoseAst::itera
return true;
}
-MatchOpCheckNode::MatchOpCheckNode(std::string nodename) {
- // convert name to same format as typeid provides;
- std::stringstream ss;
- ss << nodename.size();
- ss << nodename;
- _nodename=ss.str();
-}
+MatchOpCheckNode::MatchOpCheckNode(std::string nodename) : _nodename{nodename} {}
std::string
MatchOpCheckNode::toString() {
@@ -154,7 +148,7 @@ MatchOpCheckNode::performOperation(MatchStatus& status, RoseAst::iterator& i, S
SgNode* node=*i;
if(node!=0) {
// determine type name of node
- std::string nodeTypeName=typeid(*node).name();
+ std::string nodeTypeName= node->class_name();
if(status.debug)
std::cout << "(patternnode " << _nodename << ":" << nodeTypeName <<")";
return nodeTypeName==_nodename;
@@ -182,7 +176,7 @@ MatchOpCheckNodeSet::performOperation(MatchStatus& status, RoseAst::iterator& i
SgNode* node=*i;
if(node!=0) {
// determine type name of node
- std::string nodeTypeName=typeid(*node).name();
+ std::string nodeTypeName= node->class_name();
if(status.debug)
std::cout << "(" << _nodenameset << "," << nodeTypeName <<")";
// TODO: check of all names of the nodenameset |
|
I used the docker container. Quickly tested on 2 executables. |
|
I was able to replicate this on the docker container using |
|
Can also trigger via |
|
Good catch. So we should throw a static mutex around the |
sei-eschwartz
changed the title
!posix::pthread_mutex_destroy(&m) failed.
|
I'm not sure the best way to debug this. Maybe https://rr-project.org/? |
|
Indeed, without --threads it worked (after increasing per function memory limit). |
|
Thanks, we'll try to figure out the concurrency bug, but it's less urgent since it seems everyone can work around it.
…________________________________________
From: Trass3r ***@***.***>
Sent: Thursday, April 25, 2024 1:00 PM
To: cmu-sei/pharos
Cc: Edward J Schwartz; Assign
Subject: Re: [cmu-sei/pharos] Concurrency problems in fn2hash and other tools (Issue #267)
Warning: External Sender - do not click links or open attachments unless you recognize the sender and know the content is safe.
Indeed, without --threads it worked (after increasing per function memory limit).
—
Reply to this email directly, view it on GitHub<#267 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AL6ZAVBBXT7CXQO4XQGMDSTY7EZBTAVCNFSM6AAAAABGUPL7JKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZXG42TCNZTG4>.
You are receiving this because you were assigned.Message ID: ***@***.***>
|
|
The concurrency problem appears before the AstMatcher commit :-( |
|
Robb Matzke suggested the problem might be related to |
|
So that failed: But the Docker image is using ubuntu noble boost libraries. I'm not sure if those use pthread or not, or if it should matter. |
|
Same problem occurs even when using our own boost :-( |
After re-running it with the serialized data I get
ERROR 1: Lexical error! : <=>The text was updated successfully, but these errors were encountered: