Perf stack trace is missing __libc_start_main for some processes











up vote
1
down vote

favorite
2












I have a C++ program compiled with -fno-omit-frame-pointer. I run the same program in two processes and use perf record -p 24509,24470 -F 977 --call-graph fp -- sleep 120 then perf script to get stack traces.



What I found is that all stack traces from 24509 have main | __libc_start_main at the bottom but stack traces from 24470 only have main.



My question is why perf stack trace doesn't have __libc_start_main for one process but have it for the other process even though they are running the same program.



My perf version is 3.10.0-514.36.5.el7.x86_64.debug.






linux x86-64 glibc perf backtrace







share|improve this question
























  • Are the two processes both started from the exact same executable, or different builds of it? Are they started with the same options and environment variables? Is this repeatable if you restart the processes and run perf record again? Or even if you run perf record again without restarting them?
    – Peter Cordes
    yesterday








  • 1




    Hi @PeterCordes, those two processes are started from the exact same executable. The only difference is that they log to different log files. Also I restarted the process that's missing __libc_start_main and __libc_start_main appears after restart. If I don't restart, the process is consistently missing __libc_start_main.
    – jjyao
    10 hours ago












  • If you try repeated restarts, is it sometimes missing __libc_start_main? Or was that a one-off that you can't repeat at all? Or maybe after running for a long time, something gets overwritten on the stack and the info is lost? And BTW, command line args and the environment are on the stack on process entry, but they're above the stack frames that lead to __libc_start_main so should have no impact.
    – Peter Cordes
    9 hours ago










  • Have you upgraded your system libc.so.6 after starting the original process? Maybe perf is using stack-unwind metadata from the file of that name in the filesystem, but the libc the process still has mapped has different symbol addresses so its .eh_frame addresses don't match.
    – Peter Cordes
    9 hours ago










  • Hi @PeterCordes, you are right. I realized that after running the process for a long time, __libc_start_main may disappear. That's why I can always see __libc_start_main if I immediately run perf record after restarting the process. So my question is why the stack gets overwritten if the process runs for a long time.
    – jjyao
    6 hours ago

















up vote
1
down vote

favorite
2












I have a C++ program compiled with -fno-omit-frame-pointer. I run the same program in two processes and use perf record -p 24509,24470 -F 977 --call-graph fp -- sleep 120 then perf script to get stack traces.



What I found is that all stack traces from 24509 have main | __libc_start_main at the bottom but stack traces from 24470 only have main.



My question is why perf stack trace doesn't have __libc_start_main for one process but have it for the other process even though they are running the same program.



My perf version is 3.10.0-514.36.5.el7.x86_64.debug.






linux x86-64 glibc perf backtrace







share|improve this question
























  • Are the two processes both started from the exact same executable, or different builds of it? Are they started with the same options and environment variables? Is this repeatable if you restart the processes and run perf record again? Or even if you run perf record again without restarting them?
    – Peter Cordes
    yesterday








  • 1




    Hi @PeterCordes, those two processes are started from the exact same executable. The only difference is that they log to different log files. Also I restarted the process that's missing __libc_start_main and __libc_start_main appears after restart. If I don't restart, the process is consistently missing __libc_start_main.
    – jjyao
    10 hours ago












  • If you try repeated restarts, is it sometimes missing __libc_start_main? Or was that a one-off that you can't repeat at all? Or maybe after running for a long time, something gets overwritten on the stack and the info is lost? And BTW, command line args and the environment are on the stack on process entry, but they're above the stack frames that lead to __libc_start_main so should have no impact.
    – Peter Cordes
    9 hours ago










  • Have you upgraded your system libc.so.6 after starting the original process? Maybe perf is using stack-unwind metadata from the file of that name in the filesystem, but the libc the process still has mapped has different symbol addresses so its .eh_frame addresses don't match.
    – Peter Cordes
    9 hours ago










  • Hi @PeterCordes, you are right. I realized that after running the process for a long time, __libc_start_main may disappear. That's why I can always see __libc_start_main if I immediately run perf record after restarting the process. So my question is why the stack gets overwritten if the process runs for a long time.
    – jjyao
    6 hours ago















up vote
1
down vote

favorite
2









up vote
1
down vote

favorite
2






2





I have a C++ program compiled with -fno-omit-frame-pointer. I run the same program in two processes and use perf record -p 24509,24470 -F 977 --call-graph fp -- sleep 120 then perf script to get stack traces.



What I found is that all stack traces from 24509 have main | __libc_start_main at the bottom but stack traces from 24470 only have main.



My question is why perf stack trace doesn't have __libc_start_main for one process but have it for the other process even though they are running the same program.



My perf version is 3.10.0-514.36.5.el7.x86_64.debug.






linux x86-64 glibc perf backtrace







share|improve this question















I have a C++ program compiled with -fno-omit-frame-pointer. I run the same program in two processes and use perf record -p 24509,24470 -F 977 --call-graph fp -- sleep 120 then perf script to get stack traces.



What I found is that all stack traces from 24509 have main | __libc_start_main at the bottom but stack traces from 24470 only have main.



My question is why perf stack trace doesn't have __libc_start_main for one process but have it for the other process even though they are running the same program.



My perf version is 3.10.0-514.36.5.el7.x86_64.debug.






linux x86-64 glibc perf backtrace




linux x86-64 glibc perf backtrace






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited yesterday









Peter Cordes

115k16174300




115k16174300










asked yesterday









jjyao

100415




100415












  • Are the two processes both started from the exact same executable, or different builds of it? Are they started with the same options and environment variables? Is this repeatable if you restart the processes and run perf record again? Or even if you run perf record again without restarting them?
    – Peter Cordes
    yesterday








  • 1




    Hi @PeterCordes, those two processes are started from the exact same executable. The only difference is that they log to different log files. Also I restarted the process that's missing __libc_start_main and __libc_start_main appears after restart. If I don't restart, the process is consistently missing __libc_start_main.
    – jjyao
    10 hours ago












  • If you try repeated restarts, is it sometimes missing __libc_start_main? Or was that a one-off that you can't repeat at all? Or maybe after running for a long time, something gets overwritten on the stack and the info is lost? And BTW, command line args and the environment are on the stack on process entry, but they're above the stack frames that lead to __libc_start_main so should have no impact.
    – Peter Cordes
    9 hours ago










  • Have you upgraded your system libc.so.6 after starting the original process? Maybe perf is using stack-unwind metadata from the file of that name in the filesystem, but the libc the process still has mapped has different symbol addresses so its .eh_frame addresses don't match.
    – Peter Cordes
    9 hours ago










  • Hi @PeterCordes, you are right. I realized that after running the process for a long time, __libc_start_main may disappear. That's why I can always see __libc_start_main if I immediately run perf record after restarting the process. So my question is why the stack gets overwritten if the process runs for a long time.
    – jjyao
    6 hours ago




















  • Are the two processes both started from the exact same executable, or different builds of it? Are they started with the same options and environment variables? Is this repeatable if you restart the processes and run perf record again? Or even if you run perf record again without restarting them?
    – Peter Cordes
    yesterday








  • 1




    Hi @PeterCordes, those two processes are started from the exact same executable. The only difference is that they log to different log files. Also I restarted the process that's missing __libc_start_main and __libc_start_main appears after restart. If I don't restart, the process is consistently missing __libc_start_main.
    – jjyao
    10 hours ago












  • If you try repeated restarts, is it sometimes missing __libc_start_main? Or was that a one-off that you can't repeat at all? Or maybe after running for a long time, something gets overwritten on the stack and the info is lost? And BTW, command line args and the environment are on the stack on process entry, but they're above the stack frames that lead to __libc_start_main so should have no impact.
    – Peter Cordes
    9 hours ago










  • Have you upgraded your system libc.so.6 after starting the original process? Maybe perf is using stack-unwind metadata from the file of that name in the filesystem, but the libc the process still has mapped has different symbol addresses so its .eh_frame addresses don't match.
    – Peter Cordes
    9 hours ago










  • Hi @PeterCordes, you are right. I realized that after running the process for a long time, __libc_start_main may disappear. That's why I can always see __libc_start_main if I immediately run perf record after restarting the process. So my question is why the stack gets overwritten if the process runs for a long time.
    – jjyao
    6 hours ago


















Are the two processes both started from the exact same executable, or different builds of it? Are they started with the same options and environment variables? Is this repeatable if you restart the processes and run perf record again? Or even if you run perf record again without restarting them?
– Peter Cordes
yesterday






Are the two processes both started from the exact same executable, or different builds of it? Are they started with the same options and environment variables? Is this repeatable if you restart the processes and run perf record again? Or even if you run perf record again without restarting them?
– Peter Cordes
yesterday






1




1




Hi @PeterCordes, those two processes are started from the exact same executable. The only difference is that they log to different log files. Also I restarted the process that's missing __libc_start_main and __libc_start_main appears after restart. If I don't restart, the process is consistently missing __libc_start_main.
– jjyao
10 hours ago






Hi @PeterCordes, those two processes are started from the exact same executable. The only difference is that they log to different log files. Also I restarted the process that's missing __libc_start_main and __libc_start_main appears after restart. If I don't restart, the process is consistently missing __libc_start_main.
– jjyao
10 hours ago














If you try repeated restarts, is it sometimes missing __libc_start_main? Or was that a one-off that you can't repeat at all? Or maybe after running for a long time, something gets overwritten on the stack and the info is lost? And BTW, command line args and the environment are on the stack on process entry, but they're above the stack frames that lead to __libc_start_main so should have no impact.
– Peter Cordes
9 hours ago




If you try repeated restarts, is it sometimes missing __libc_start_main? Or was that a one-off that you can't repeat at all? Or maybe after running for a long time, something gets overwritten on the stack and the info is lost? And BTW, command line args and the environment are on the stack on process entry, but they're above the stack frames that lead to __libc_start_main so should have no impact.
– Peter Cordes
9 hours ago












Have you upgraded your system libc.so.6 after starting the original process? Maybe perf is using stack-unwind metadata from the file of that name in the filesystem, but the libc the process still has mapped has different symbol addresses so its .eh_frame addresses don't match.
– Peter Cordes
9 hours ago




Have you upgraded your system libc.so.6 after starting the original process? Maybe perf is using stack-unwind metadata from the file of that name in the filesystem, but the libc the process still has mapped has different symbol addresses so its .eh_frame addresses don't match.
– Peter Cordes
9 hours ago












Hi @PeterCordes, you are right. I realized that after running the process for a long time, __libc_start_main may disappear. That's why I can always see __libc_start_main if I immediately run perf record after restarting the process. So my question is why the stack gets overwritten if the process runs for a long time.
– jjyao
6 hours ago






Hi @PeterCordes, you are right. I realized that after running the process for a long time, __libc_start_main may disappear. That's why I can always see __libc_start_main if I immediately run perf record after restarting the process. So my question is why the stack gets overwritten if the process runs for a long time.
– jjyao
6 hours ago



















active

oldest

votes











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














 

draft saved


draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53401691%2fperf-stack-trace-is-missing-libc-start-main-for-some-processes%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown






























active

oldest

votes













active

oldest

votes









active

oldest

votes






active

oldest

votes
















 

draft saved


draft discarded



















































 


draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53401691%2fperf-stack-trace-is-missing-libc-start-main-for-some-processes%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







-

Popular posts from this blog

Berounka

Image
Berounka.mw-parser-output .entete.map{background-image:url("//upload.wikimedia.org/wikipedia/commons/7/7a/Picto_infobox_map.png")} Caractéristiques Longueur 139  km Bassin 8 861  km 2 Bassin collecteur Elbe Débit moyen ? Cours Source Confluence de la Mže et de la Radbuza · Localisation Pilsen · Altitude 305  m · Coordonnées 49° 45′ 13″ N, 13° 23′ 24″ E Confluence Vltava · Localisation Prague · Altitude 187  m · Coordonnées 49° 59′ 43″ N, 14° 24′ 04″ E Géographie Pays traversés   République tchèque modifier   La Berounka est une rivière de la République tchèque. Elle porte le nom de Mže depuis sa source en Allemagne près de la frontière jusqu'à sa confluence avec la Radbuza à Plzeň. Elle continue ensuite sous le nom de Berounka jusqu'à sa confluence avec la Vltava, près de Prague. La rivière est une destination prisée pour les amateurs de canoë, qui appréc...
Read more

Sphinx de Gizeh

Image
Pour les articles homonymes, voir Sphinx. Sphinx de Gizeh.mw-parser-output .entete.egypte-antique{background-image:url("//upload.wikimedia.org/wikipedia/commons/c/cc/Picto_infobox_ancient_Egypt.png")} Site d'Égypte antique Le visage du sphinx de Gizeh. Noms en arabe أبو الهول , Abou al-Hôl Localisation Région Basse-Égypte Coordonnées 29° 58′ 31″ nord, 31° 08′ 16″ est Géolocalisation sur la carte : Égypte Sphinx de Gizeh modifier   Le sphinx de Gizeh est la statue thérianthrope qui se dresse devant les grandes pyramides du plateau de Gizeh, en Basse-Égypte. Sculpture monumentale monolithique la plus grande du monde [ 1 ] avec 73,5 mètres de longueur, 14 mètres de largeur et 20,22 mètres de hauteur, elle représente un sphinx couchant. Réalisée vers -2500, elle serait attribuée à Djédefrê, l'un des pharaons de la IV e  dynastie, représentant son père le pharaon Khéops. Sommaire 1 Étymologie 2 Desc...
Read more

Different font size/position of beamer's navigation symbols template's content depending on regular/plain...

Image
3 Let's suppose I'd like to divert the navigation symbols template (e.g. in order replace them by the frame numbers, see this bug report ;) I would be facing troubles regarding the font size/position, depending on regular/plain frames, as shown by the following MCE. How could I get rid of these troubles? documentclass{beamer} usetheme{PaloAlto} setbeamertemplate{navigation symbols}{insertframenumber/inserttotalframenumber} begin{document} begin{frame} frametitle{A regular frame} end{frame} begin{frame}[plain] frametitle{A plain frame} end{frame} end{document} beamer header-footer share | improve this question asked Dec 10 '18 a...
Read more