Petr Vandrovec wrote:
Replace call to sleep() with busy loop. Glibc's sleep() uses %ebp for
its own data, so when you interrupt sleep(), you get rbp=(unsigned
int)-1,
as rbp really contains 0x0000.0000.ffff.ffff when nanosleep() syscall
is issued.
Petr
From what I understand, when you signal a thread, the signal handler
executes in the thread context and not the main process context. So
therefore the rbp would be the thread's copy and not the one that
sleep() just modified. So whatever sleep does to the main process
context, there shouldn't be any effect on the thread context.... Also,
what can I call to allow the threads to run? sleep() allows me to run
the other threads. Busy wait does not.....
I do not understand. You call sleep() from both threads you spawn
(as well from main), so both threads are always interrupted in the
sleep(2). Load your process to the debugger...
#0 tb_sig_handler (sig=33, info=0x407ff2f0, ucontext=0x407ff1c0) at
ttest1.c:26
#1 <signal handler called>
#2 0x00002aaaaad81335 in nanosleep () from /lib/libc.so.6
#3 0x00002aaaaad811a5 in sleep () from /lib/libc.so.6
#4 0x0000000000400871 in test_thread1 (arg=0x0) at ttest1.c:40
#5 0x00002aaaaabc6b55 in start_thread () from /lib/libpthread.so.0
#6 0x00002aaaaada87f0 in clone () from /lib/libc.so.6
Ooops, you are right. I forgot about those ones in the threads. Yes you
are right. Once the sleep goes away rBP displays the correct values. Is
this issue due to glibc or because of the toolchain? I do not have this
issues on 32bit x86.... I would assume that the reason it works on
Mandrake is due to the toolchain they use versus other distros? The
toolchain determines which registers to use and the
-fno-omit-frame-pointer did not prevent some of them from clobbering rbp?
--
Dave
------------------------------------------------------
Dave Jiang
Software Engineer Phone: (480) 517-0372
MontaVista Software, Inc. Fax: (480) 517-0262
2141 E Broadway Rd, St 108 Web: www.mvista.com
Tempe, AZ 85282 mailto:[email protected]
------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |