Tue, 02 Jan 2001 Yuhong Ren wrote:
> Dear Gordon and All,
>
> Thanks for your kind advice. I debugged it using Rhide, and when it gets
> through the Destructor part, it gives error message: "Segmentation fault",
> then says " Could not find the source file memcpy.c". I am puzzled with
> this, what's the matter with "memcpy.c" ?
This means that the error is in the code generated from "memcpy.c", which is
the source of the standard C library. (Or perhaps it's in the kernel tree? Not
sure.) The debugger complains about not being able to find the file "memcpy.c"
that the debug info of libc is referring to.
Anyway, it's rather unlikely that the error actually is in memcpy.c. What is
more likely is that the crash is caused by someone passing the wrong source or
destination address, or to big a size argument to memcpy(). A stack trace would
reveal the path that lead to the crash in memcpy().
> Another very strange phenomenon is that, I put a QMessageBox in the
> Destructor in order to check if Destructor really run, but I found that the
> Destructor doesn't run when I close the class, strangely, the QMessageBox
> appears when I open the class for the second time. What's wrong with this
> ???
I'm not experienced enough with Qt to tell why this happens, but it's not
entirely surprizing to me, considering how the majority of toolkits are
constructed.
Is there some kind of garbage collection system involved? Do you free objects
directly, or do you use functions or members of other objects to do that? Is
the message pump/loop allowed to run some time between the destruction and the
instantiation of the new object? (May not be entirely under your control.) Are
you performing the destruction in the correct way, allowing the C++ OO and/or
Qt to find the right destructor?
There are many reasons why you may see this kind of things, but the majority of
times I've seen similar things, it's been because of mixed up pointers, array
overwrites, erranuous class typecasts and the like. (Mostly things caused by
bad programming style, that is. ;-)
> Moreover, in my codes, I didn't use anything related with QGArray, I just
> Open/Close the real time FIFO under RT Linux, so, how could I debug into
> the QGArray errors ??
Any Qt widgets? (I'd guess they use various low level constructs such as
arrays, lists etc...)
In the case of a pointer error or buffer overflow in a read(), memcpy() or
similar operation, it's not surprizing if you see crashes related to objects
totally unrelated to the error itself. In this case, your read() could be
overwriting all or part of a QGArray, or some other object with references to a
QGArray.
//David
..- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
`----------------------> http://www.linuxaudiodev.com/maia -'
..- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`--------------------------------------> [EMAIL PROTECTED] -'
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
