When a process.mark() probe is in the .probes section multiple times with different addresses it looks like only one address is being triggered for a probe on the mark() for that name (and it is triggered multiple times for that one address). One example is the cxxclass.exp test on i386: > $ stap ./systemtap.base/cxxclass.stp cxxclass.exe -c ./cxxclass.exe > main_enter > call: 64 > cons call: 64 > cons call: 64 > meth call: 64 24 > meth call: 64 24 > dest call: 42 > dest call: 42 > call2: 24 > main_exit > > Seems there is double call on process.mark. The issue seems to be that some of the static probe points get duplicated in the code. This shouldn't be a problem, and the .probes section does contain both places with different addresses. You can also see (with enough -vvvvv) that stap finds both locations while resolving the mark("cons") probe. But, only the first is registered twice, as can be seen in the generated code: { .address=(unsigned long)0x8048476ULL, .pp="process(\"/home/mark/src/systemtap/testsuite/cxxclass.exe\").statement(134513782)", .ph=&probe_1895, }, { .address=(unsigned long)0x8048476ULL, .pp="process(\"/home/mark/src/systemtap/testsuite/cxxclass.exe\").statement(134513782)", .ph=&probe_1895, }, This means the first call of the constructor is triggered as probe twice (as is the method, and destructor call) but the second call isn't triggered as probe at all. It looks like this is a problem in how sdt_query::convert_location() is called (it seems to do duplication detection based on probe name, but not address. I haven't looked very deeply into it yet though.
Seeing the same issue on x86_64 btw, so it isn't i386 specific. GCC: 4.4.2 [gcc (GCC) 4.4.2 20091027 (Red Hat 4.4.2-7)]
This is because g++ 4.4.2 is now laying out the .probes section differently.
Created attachment 4469 [details] .probes for 4.4.1 and 4.4.2
commit 39a3e39706 A component was being reused instead of recreated. (Oddly enough this works okay with an older version of stap I have hanging around.