[linrad] Re: xlinrad 02.05. Problem solved(?)
The first one cannot know whether or not a separate thread using a
pointer or the variable has initialized the contents. In the second,
typically the construct inside the
if (A ==0) {
}
braces, requires that A be initialized to zero and that some action
required by the inside of braces area has been accomplished. Otherwise,
there would be no need for the if test. This is typically why the
second fails and the first does not. If A is an unsigned integer
quantity, it does not matter that B is unitialized. The operation is
legal even if the contents are not. These kinds of assignments
typically succeed except in the case of floating point where a floating
point exception is thrown (if you are lucky!).
gdb and valgrind are tools that aid (as you can see) but they cannot
tease apart all of the logical ways things can happen. If I may, they
are not mind readers, they are the assistant in the audience aiding the
mentalist by picking the unsuspecting customer's pocket for
information! With that attitude, you will find a way to properly use
valgrind or gdb to eventually come to arrive at the error by logical
inference and deduction. I wish I could give a more satisfying answer
but you can see why it is not possible for valgrind or gdb to understand
all of the ways these things can happen.
The best case you can hope for is an explosion where valgrind gives you
the line of interest and you back it up logically to the nexus of the
problem.
73's
Bob
[EMAIL PROTECTED] wrote:
Hi Bob,
You will probably need to turn on the debug symbol generation and turn
off optimizations and then you will be able to follow the progress. You
do not care that it is slow here, you are attempting to find logic and
other errors.
OK. The problem is to know all the details
gcc -g -O0 will turn off optimizations, insert debug symbols and you
can then debug with gdb or valgrind.
Hmmm, so far gdb is black magic to me, but valgrind gives
info I can understand:-)
I tried several times (various things) until I discovered I have to
put -g in the compiler stage and not the linker stage;-)
Another thing was that I had to remove -s from the linker options
Now it works!
Is there a way to get an error message when an uninited variable
is used ? Things like this:
(B not initialised)
A=B;
.
.
.
.
if(A==0)whatever();
I get an error message from the last line but not from the first one
which may be very far away in the code an have inherited its non-init
status through a long chain through several intermediate variables.
73
Leif
--
AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats,
NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman
Laziness is the number one inspiration for ingenuity. Guilty as charged!
#
This message is sent to you because you are subscribed to
the mailing list linrad@antennspecialisten.se.
To unsubscribe, E-mail to: [EMAIL PROTECTED]
To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED]
To switch to the INDEX mode, E-mail to [EMAIL PROTECTED]
Send administrative queries to [EMAIL PROTECTED]
[linrad] Re: xlinrad 02.05. Problem solved(?)
Robert McGwier wrote: Unfortunately, I do not believe valgrind is available under windows and it would be very difficult to make valgrind work because of the myriad differences between process/threads on windows and on all real operating systems. ;-). Under Windows there are tools specific to the compiler used. As an example, if you use the C++ compiler from Borland, it comes with CodeGuard, a powerful tool for detecting resource leaks, out-of-bounds accesses, uninitialized variables, and a plethora of all the other sins that a programmer normally commits... :-) 73 Alberto I2PHD # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[linrad] Re: xlinrad 02.05. Problem solved(?)
[EMAIL PROTECTED] wrote: Hi All, Moving the mouse is still the culprit that causes crashes better than anything else I do. I do not see a spike on the System Monitor CPU usage [or on the Linrad CPU usage indicator], but perhaps the spike is too brief. My system runs about 15% or less CPU usage with 96000 Hz sampling, 4 channel input. When I run 'valgrind xlinrad', then CPU usage is 98%PLUS and it is not possible to make xlinrad crash with anything I have done. xlinrad runs very slowly, and there is a speed error with the sampling rate only 35000-48000 instead of 96000. It seems Pierre, ON5GN has fount the real bug! A multi-threaded program has to call XInitThreads() as the first call to the X server. I did not know about this so it is not done in xlinrad. Another X11 error is that the first XPutImage() must be delayed until the first Expose event has happened. Presumably valgrind does these things properly for Linrad:-) I was unaware of valgrind and its easy use. It seems I could find and correct many bugs that have not given any symptoms(yet) in a very easy way so it should be a time saver:-) I am not a programmer, my interest is signal processing and the fundamentals of the algorithms involved. Maybe there are other little 'hints' that would make things easier and faster. Is there a 'valgrind' for Windows for example? Baahhh Humbug. A programmer is someone who writes effective programs that accomplish a task. You have certainly done that and you have produced now the version that will carry this work forward for a while. Unfortunately, I do not believe valgrind is available under windows and it would be very difficult to make valgrind work because of the myriad differences between process/threads on windows and on all real operating systems. ;-). Pierre told me that XInitThreads makes the ESC not work any more. I have no idea why and I can not check it or anything else because the P4 machine is busy installing Debian Sarge from the internet. It reports 12 more hours to go. I started install 14 hours ago, this time a reasonably complete installation because it is so difficult to find out what package to download when something is missing. Once I can put the current developement disk (Debian Etch) back into the computer I will try to implement XInitThreads and have a check with valgrind. Do not waste more time on xlinrad-2.05, I will upload 2.06 as soon as possible:-) Reports on 02-05 bugs under Windows and with svgalib are still welcome! 73 Leif / SM5BSZ -- AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman Laziness is the number one inspiration for ingenuity. Guilty as charged! # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[linrad] Re: xlinrad 02.05. Problem solved(?)
Hi Bob, Baahhh Humbug. A programmer is someone who writes effective programs that accomplish a task. You have certainly done that and you have produced now the version that will carry this work forward for a while. Unfortunately, I do not believe valgrind is available under windows and it would be very difficult to make valgrind work because of the myriad differences between process/threads on windows and on all real operating systems. ;-). What I mean is that I can not understand the manuals programmers write for each other. There is a whole language that I can not grasp and I just get confused. I have no problem reading the Intel definitions of the assembly language however. Those are written in normal technical language:-) I have spent some time trying to understand how to get more info out of valgrind. When valgrind points to an address I have no way of finding out what line in the C-code it corresponds to. The assembly routines are easy. I know what each line means and where it is located:-) The valgrind documentation is far too big like the gcc documentation. It is impossible for me to grasp:-( Nearly all the Linrad code is identical for svgalib, X11 and Windows so I can find nearly everything with valgrind under X11. Is there a way to find the line numbers of the C-code? I know from the map where a routine starts. In an assembly program I can insert public labels reasonably close to where the problem is and then compute approximately where the error is and move the label. Within two or three iterations I find the offending statement. Not so under C. What is the proper way to handle this? 73 Leif / SM5BSZ # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
[linrad] Re: xlinrad 02.05. Problem solved(?)
Leif: You will probably need to turn on the debug symbol generation and turn off optimizations and then you will be able to follow the progress. You do not care that it is slow here, you are attempting to find logic and other errors. gcc -g -O0 will turn off optimizations, insert debug symbols and you can then debug with gdb or valgrind. Valgrind will take you to the very line (not sure about the assembly routines) of the problem. Bob [EMAIL PROTECTED] wrote: Hi Bob, Baahhh Humbug. A programmer is someone who writes effective programs that accomplish a task. You have certainly done that and you have produced now the version that will carry this work forward for a while. Unfortunately, I do not believe valgrind is available under windows and it would be very difficult to make valgrind work because of the myriad differences between process/threads on windows and on all real operating systems. ;-). What I mean is that I can not understand the manuals programmers write for each other. There is a whole language that I can not grasp and I just get confused. I have no problem reading the Intel definitions of the assembly language however. Those are written in normal technical language:-) I have spent some time trying to understand how to get more info out of valgrind. When valgrind points to an address I have no way of finding out what line in the C-code it corresponds to. The assembly routines are easy. I know what each line means and where it is located:-) The valgrind documentation is far too big like the gcc documentation. It is impossible for me to grasp:-( Nearly all the Linrad code is identical for svgalib, X11 and Windows so I can find nearly everything with valgrind under X11. Is there a way to find the line numbers of the C-code? I know from the map where a routine starts. In an assembly program I can insert public labels reasonably close to where the problem is and then compute approximately where the error is and move the label. Within two or three iterations I find the offending statement. Not so under C. What is the proper way to handle this? 73 Leif / SM5BSZ # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED] -- AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman Laziness is the number one inspiration for ingenuity. Guilty as charged! # This message is sent to you because you are subscribed to the mailing list linrad@antennspecialisten.se. To unsubscribe, E-mail to: [EMAIL PROTECTED] To switch to the DIGEST mode, E-mail to [EMAIL PROTECTED] To switch to the INDEX mode, E-mail to [EMAIL PROTECTED] Send administrative queries to [EMAIL PROTECTED]
