Is there a “low level” way of determining what syscalls a process are calling?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
2
down vote

favorite












I have a binary that is freezing, and that binary happens to be my package manager, preventing me from installing any new packages.



Running under gdb, I can get a back trace when the process is frozen, and I get:



#0 0xb6cd9abc in syscall () from /lib/libc.so.6 
#1 0xb60a99b0 in startParsing () from /usr/lib/libexpat.so.1


So it looks like expat is making a syscall that never returns.



Is there a "low level" way for me to find out more about that syscall? I'd like to install strace, but since this is my package manager failing, I can't easily get strace onto the machine.



The CPU is arm, making it slightly more complicated to download ready made binaries.







share|improve this question





















  • You can get strace easily: download the package, unpack it yourself, then run.
    – Ipor Sircer
    May 8 at 15:38










  • Probably depends on the operating system you're running. Linux? Some BSD? Something else?
    – ilkkachu
    May 8 at 15:46










  • @ilkkachu Linux. I've tagged the question as such.
    – user50849
    May 8 at 15:54










  • Why not inspect the memory address assigned to StartParsing()? strace isn't going to give you any more than gdb or mdb. More than likely the file StartParsing() is working on is large, how long did you let it run?
    – jas-
    May 8 at 16:10











  • @jas- Actually strace will give you much more information. strace will tell you what call was made, and the arguments to it. GDB does not provide this as the debugging symbols have been stripped out.
    – Patrick
    May 8 at 17:20















up vote
2
down vote

favorite












I have a binary that is freezing, and that binary happens to be my package manager, preventing me from installing any new packages.



Running under gdb, I can get a back trace when the process is frozen, and I get:



#0 0xb6cd9abc in syscall () from /lib/libc.so.6 
#1 0xb60a99b0 in startParsing () from /usr/lib/libexpat.so.1


So it looks like expat is making a syscall that never returns.



Is there a "low level" way for me to find out more about that syscall? I'd like to install strace, but since this is my package manager failing, I can't easily get strace onto the machine.



The CPU is arm, making it slightly more complicated to download ready made binaries.







share|improve this question





















  • You can get strace easily: download the package, unpack it yourself, then run.
    – Ipor Sircer
    May 8 at 15:38










  • Probably depends on the operating system you're running. Linux? Some BSD? Something else?
    – ilkkachu
    May 8 at 15:46










  • @ilkkachu Linux. I've tagged the question as such.
    – user50849
    May 8 at 15:54










  • Why not inspect the memory address assigned to StartParsing()? strace isn't going to give you any more than gdb or mdb. More than likely the file StartParsing() is working on is large, how long did you let it run?
    – jas-
    May 8 at 16:10











  • @jas- Actually strace will give you much more information. strace will tell you what call was made, and the arguments to it. GDB does not provide this as the debugging symbols have been stripped out.
    – Patrick
    May 8 at 17:20













up vote
2
down vote

favorite









up vote
2
down vote

favorite











I have a binary that is freezing, and that binary happens to be my package manager, preventing me from installing any new packages.



Running under gdb, I can get a back trace when the process is frozen, and I get:



#0 0xb6cd9abc in syscall () from /lib/libc.so.6 
#1 0xb60a99b0 in startParsing () from /usr/lib/libexpat.so.1


So it looks like expat is making a syscall that never returns.



Is there a "low level" way for me to find out more about that syscall? I'd like to install strace, but since this is my package manager failing, I can't easily get strace onto the machine.



The CPU is arm, making it slightly more complicated to download ready made binaries.







share|improve this question













I have a binary that is freezing, and that binary happens to be my package manager, preventing me from installing any new packages.



Running under gdb, I can get a back trace when the process is frozen, and I get:



#0 0xb6cd9abc in syscall () from /lib/libc.so.6 
#1 0xb60a99b0 in startParsing () from /usr/lib/libexpat.so.1


So it looks like expat is making a syscall that never returns.



Is there a "low level" way for me to find out more about that syscall? I'd like to install strace, but since this is my package manager failing, I can't easily get strace onto the machine.



The CPU is arm, making it slightly more complicated to download ready made binaries.









share|improve this question












share|improve this question




share|improve this question








edited May 8 at 15:53
























asked May 8 at 15:37









user50849

1,43741524




1,43741524











  • You can get strace easily: download the package, unpack it yourself, then run.
    – Ipor Sircer
    May 8 at 15:38










  • Probably depends on the operating system you're running. Linux? Some BSD? Something else?
    – ilkkachu
    May 8 at 15:46










  • @ilkkachu Linux. I've tagged the question as such.
    – user50849
    May 8 at 15:54










  • Why not inspect the memory address assigned to StartParsing()? strace isn't going to give you any more than gdb or mdb. More than likely the file StartParsing() is working on is large, how long did you let it run?
    – jas-
    May 8 at 16:10











  • @jas- Actually strace will give you much more information. strace will tell you what call was made, and the arguments to it. GDB does not provide this as the debugging symbols have been stripped out.
    – Patrick
    May 8 at 17:20

















  • You can get strace easily: download the package, unpack it yourself, then run.
    – Ipor Sircer
    May 8 at 15:38










  • Probably depends on the operating system you're running. Linux? Some BSD? Something else?
    – ilkkachu
    May 8 at 15:46










  • @ilkkachu Linux. I've tagged the question as such.
    – user50849
    May 8 at 15:54










  • Why not inspect the memory address assigned to StartParsing()? strace isn't going to give you any more than gdb or mdb. More than likely the file StartParsing() is working on is large, how long did you let it run?
    – jas-
    May 8 at 16:10











  • @jas- Actually strace will give you much more information. strace will tell you what call was made, and the arguments to it. GDB does not provide this as the debugging symbols have been stripped out.
    – Patrick
    May 8 at 17:20
















You can get strace easily: download the package, unpack it yourself, then run.
– Ipor Sircer
May 8 at 15:38




You can get strace easily: download the package, unpack it yourself, then run.
– Ipor Sircer
May 8 at 15:38












Probably depends on the operating system you're running. Linux? Some BSD? Something else?
– ilkkachu
May 8 at 15:46




Probably depends on the operating system you're running. Linux? Some BSD? Something else?
– ilkkachu
May 8 at 15:46












@ilkkachu Linux. I've tagged the question as such.
– user50849
May 8 at 15:54




@ilkkachu Linux. I've tagged the question as such.
– user50849
May 8 at 15:54












Why not inspect the memory address assigned to StartParsing()? strace isn't going to give you any more than gdb or mdb. More than likely the file StartParsing() is working on is large, how long did you let it run?
– jas-
May 8 at 16:10





Why not inspect the memory address assigned to StartParsing()? strace isn't going to give you any more than gdb or mdb. More than likely the file StartParsing() is working on is large, how long did you let it run?
– jas-
May 8 at 16:10













@jas- Actually strace will give you much more information. strace will tell you what call was made, and the arguments to it. GDB does not provide this as the debugging symbols have been stripped out.
– Patrick
May 8 at 17:20





@jas- Actually strace will give you much more information. strace will tell you what call was made, and the arguments to it. GDB does not provide this as the debugging symbols have been stripped out.
– Patrick
May 8 at 17:20











1 Answer
1






active

oldest

votes

















up vote
2
down vote



accepted










Assuming you have strace installed:



strace /path/to/binary



edit: I didn't read the last bit which said you don't have strace, you should be able to download a strace tarball and build it without using your package manager. You could build it statically on another machine and copy it across if you don't have build tools installed.






share|improve this answer





















  • I ended up solving it by downloading strace source and compiling it.
    – user50849
    May 10 at 16:24










Your Answer







StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
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: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);








 

draft saved


draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f442581%2fis-there-a-low-level-way-of-determining-what-syscalls-a-process-are-calling%23new-answer', 'question_page');

);

Post as a guest






























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
2
down vote



accepted










Assuming you have strace installed:



strace /path/to/binary



edit: I didn't read the last bit which said you don't have strace, you should be able to download a strace tarball and build it without using your package manager. You could build it statically on another machine and copy it across if you don't have build tools installed.






share|improve this answer





















  • I ended up solving it by downloading strace source and compiling it.
    – user50849
    May 10 at 16:24














up vote
2
down vote



accepted










Assuming you have strace installed:



strace /path/to/binary



edit: I didn't read the last bit which said you don't have strace, you should be able to download a strace tarball and build it without using your package manager. You could build it statically on another machine and copy it across if you don't have build tools installed.






share|improve this answer





















  • I ended up solving it by downloading strace source and compiling it.
    – user50849
    May 10 at 16:24












up vote
2
down vote



accepted







up vote
2
down vote



accepted






Assuming you have strace installed:



strace /path/to/binary



edit: I didn't read the last bit which said you don't have strace, you should be able to download a strace tarball and build it without using your package manager. You could build it statically on another machine and copy it across if you don't have build tools installed.






share|improve this answer













Assuming you have strace installed:



strace /path/to/binary



edit: I didn't read the last bit which said you don't have strace, you should be able to download a strace tarball and build it without using your package manager. You could build it statically on another machine and copy it across if you don't have build tools installed.







share|improve this answer













share|improve this answer



share|improve this answer











answered May 8 at 15:44









rusty shackleford

1,145115




1,145115











  • I ended up solving it by downloading strace source and compiling it.
    – user50849
    May 10 at 16:24
















  • I ended up solving it by downloading strace source and compiling it.
    – user50849
    May 10 at 16:24















I ended up solving it by downloading strace source and compiling it.
– user50849
May 10 at 16:24




I ended up solving it by downloading strace source and compiling it.
– user50849
May 10 at 16:24












 

draft saved


draft discarded


























 


draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f442581%2fis-there-a-low-level-way-of-determining-what-syscalls-a-process-are-calling%23new-answer', 'question_page');

);

Post as a guest













































































Popular posts from this blog

How to check contact read email or not when send email to Individual?

Bahrain

Postfix configuration issue with fips on centos 7; mailgun relay