hi
this is the command line binary string that is reference to in the bug
gen-report as 5951
67 69 73 74 65 72 36 34 5F 74 68 72 65 61 64 5F 61 gister64_thread_a
this is what i can gather from the log
# 0 kernel system call - enter stack -leaving user mode and entering
kernel process
# 1 waitpid call is inconclusive as to the function error such as
The waitpid function suspends execution of the current
process until a child as specified by the pid argument has
exited, or until a signal is delivered whose action is to
terminate the current process or to call a signal handling
function. If a child as requested by pid has already
exited by the time of the call (a so-called "zombie" pro-
cess), the function returns immediately. Any system
resources used by the child are freed.
The value of pid can be one of:
< -1 which means to wait for any child process whose
process group ID is equal to the absolute value of
-1 which means to wait for any child process whose
process group ID is equal to the absolute value of
pid.
-1 which means to wait for any child process; this is
the same behaviour which wait exhibits.
0 which means to wait for any child process whose
process group ID is equal to that of the calling
process.
> 0 which means to wait for the child whose process ID
is equal to the value of pid.
The value of options is an exclusive OR of zero or more of
the following constants:
as well
0xb72876cb is not found in the binary source using bless
# 3 Here is a minimal example program. It uses the alarm() function to
limit the time spent waiting to open a file; this is useful if the file
is for a serial device that may not be turned on, which would normally
cause the os.open() to hang indefinitely. The solution is to set a
5-second alarm before opening the file; if the operation takes too long,
the alarm signal will be sent, and the handler raises an exception.
import signal, os
def handler(signum, frame):
print 'Signal handler called with signal', signum
raise IOError, "Couldn't open device!"
# Set the signal handler and a 5-second alarm
signal.signal(signal.SIGALRM, handler)
signal.alarm(5)
# This open() may hang indefinitely
fd = os.open('/dev/ttyS0', os.O_RDWR)
signal.alarm(0) # Disable the alarm
im really unsure if its system related because of the cpu
interface or if its more toward these lines
It means that GDB thinks that a signal handler has been invoked, and
that the frames above it are in the signal handler context. If that's
incorrect, you've found a bug in GDB.
this may all be a waste of space as i am a noob and ever yet unlearned at this
code but thats all i have time to do today
peace =]
** Changed in: xubuntu-meta (Ubuntu)
Sourcepackagename: None => xubuntu-meta
--
unsure of nature xubuntu ISSUE
https://bugs.launchpad.net/bugs/209468
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
