Error about ltrace

[upojzsb]

I'm now learning something about linux, and learned something about ltrace and strace, so I installed ltrace by pacman, and I run it like this:
[root@alarmpi ~]# ltrace ls
__libc_start_main(0x12088, 1, 0x7eec2d94, 0x22b04PTRACE_SINGLESTEP: Input/output error
2587 couldn't continue when handling __libc_start_main (0x11e18) at 0x11e18

I want to know why ltrace doesn't work.Thanks.

[sdjf]

I have never used ltrace (I use strace instead) but since no one else has answered you, may I ask if you put your error into google? If you search the following, you will see there are others reporting it as a bug.

Code: Select all

2587 couldn't continue when handling __libc_start_main 

My question is whether "ls" is the best command to use for learning how to use the command. I don't even know if the "ls" command calls any libraries, and ltrace is for tracing library calls. Maybe "ls" calls some, I don't know for sure.

Have you tried installing and running "strace" on ls and comparing the results? That traces all system calls.

I generally just use strace when I need to see why a command or program is crashing, not sure when you would need to actually use ltrace instead, when it is more limited.

[upojzsb]

I have never used ltrace (I use strace instead) but since no one else has answered you, may I ask if you put your error into google? If you search the following, you will see there are others reporting it as a bug.

Code: Select all

2587 couldn't continue when handling __libc_start_main 

My question is whether "ls" is the best command to use for learning how to use the command. I don't even know if the "ls" command calls any libraries, and ltrace is for tracing library calls. Maybe "ls" calls some, I don't know for sure.

Have you tried installing and running "strace" on ls and comparing the results? That traces all system calls.

I generally just use strace when I need to see why a command or program is crashing, not sure when you would need to actually use ltrace instead, when it is more limited.

I have used the ltrace on a x86 architecture's computer and a result which is different form strace came out.I searched this error on Google and knew it's a bug but didn't know how to solve it.
As for strace, I used it and got expected result.I just want to know why ltrace doesn't work.
Thank you for your answer.

[sdjf]

If ltrace has a known bug, then it would not be a raspberry pi archlinuxarm issue and the place to discuss solving it, I think, would be what is called "upstream", where ltrace comes from. Is it a general ltrace bug?

Maybe someone else here can answer your question, but if not, then it might be worth asking it somewhere that lots of people post who mention using ltrace.

[upojzsb]

If ltrace has a known bug, then it would not be a raspberry pi archlinuxarm issue and the place to discuss solving it, I think, would be what is called "upstream", where ltrace comes from. Is it a general ltrace bug?

Maybe someone else here can answer your question, but if not, then it might be worth asking it somewhere that lots of people post who mention using ltrace.

I searched it on Google just now and found out this: https://git.busybox.net/buildroot/commi ... d9b4f64eb0
It seemed that this is not a bug but a change for linux on ARM.

I'm sorry for not carefully look at Google 's search results because I have to use a VPN to tunnel through Google .
Thank you for your answer

[sdjf]

They still say it is broken and needs fixing with "Master", the way I read what you gave link for.

Maybe you should report the package problem at the ArchLinuxArm forum, the one for problems with packages? You will need to read the instructions for posting there, to make sure it is the right place, and they still might say to report it "upstream".

http://archlinuxarm.org/forum/viewforum.php?f=15

But if strace will do what you need, it may not be worth the hassle of figuring this out?