pizzi@esacs.UUCP (Riccardo Pizzi) (08/02/90)
I decided to write a simple test program for the FileSelectionBox widget
and discovered some nasty and (let me say it) stupid bugs.
They pertains to the DoSearch() routines and will very likely cause
random core dumps. BTW, that's Motif 1.0a, no 1.1 yet... :-(
I don't know if these bugs are already in some official bugs list, so I
will post them anyway.
SYMPTOMS: if you fill the File Filter field with a bad path,
the application dies.
Pick up the FileSB.c file and look at line 907 in DoFileSearch()... you
can see here that, if there are no matching files in the search directory,
a standard "<No Match>" line is placed in the list and the num_files
variable is set to 1.
Now the ugly stuff... around line 959 they tries to free some memory that
in case of no matching files has not been effectively allocated.
To fix, either use strdup() at 907 or put an "if (!no_match)" before line 957.
SYMPTOMS: Calling XmFileSelectionDoSearch() sometimes the application dies.
In the same file as above (FileSB.c), in the public routine
XmFileSelectionDoSearch() there are two very obvious mistakes... look at lines
1726 and 1739, you can very easily see that the call to XmStringLength()
looks somewhat strange... in fact, there should be an XmString as parameter
to the function and not an int! To fix, put search_data.value instead of
search_data.length at line 1726 and search_data.mask at line 1739.
That's all... this is the result of my first experience with this widget
(I never used it before), but it is clear to me that this part of the Motif
code has *never* been tested by the dev team :-(
l8er...
- Rick -
--
Riccardo Pizzi @ ESA Software, Rimini, Italy
This is a hand-made signature.
--
Riccardo Pizzi @ ESA Software srl - ITALY
uunet: ....mcsun!i2unix!esacs!pizzi
voice: (0039) 541 741113 fax: (0039) 541 742153
UnixBBS: (0039) 541 27858 PEPron@kasparov.osf.org (Ron Birnbaum) (08/04/90)
In article <1202@esacs.UUCP> pizzi@esacs.UUCP (Riccardo Pizzi) writes: >I decided to write a simple test program for the FileSelectionBox widget >and discovered some nasty and (let me say it) stupid bugs. >They pertains to the DoSearch() routines and will very likely cause >random core dumps. BTW, that's Motif 1.0a, no 1.1 yet... :-( >I don't know if these bugs are already in some official bugs list, so I >will post them anyway. ... >That's all... this is the result of my first experience with this widget >(I never used it before), but it is clear to me that this part of the Motif >code has *never* been tested by the dev team :-( Well, I think you'll like the File Selection Box much better in Motif 1.1. It has been completely re-written and it works much better! Ron Birnbaum OSF Systems Engineering ron@osf.org
dbrooks@osf.osf.org (David Brooks) (08/04/90)
In article <1202@esacs.UUCP> pizzi@esacs.UUCP (Riccardo Pizzi) writes: >I decided to write a simple test program for the FileSelectionBox widget >and discovered some nasty and (let me say it) stupid bugs.... >I don't know if these bugs are already in some official bugs list, so I >will post them anyway. Since you have access to source (at least 1.0.A), you have access to an open bug list. Please refer to it. It will help us all. Your first bug appeared as PIR number 709; it got duplicated as 969 later. [...problem with freeing "No Match" string...] >To fix, either use strdup() at 907 or put an "if (!no_match)" before line 957. Not quite. Before line 959. This one is a little subtle. >...to the function and not an int! To fix, put search_data.value instead of >search_data.length at line 1726 and search_data.mask at line 1739. PIR 910. Fixed in 1.0.3. > >That's all... this is the result of my first experience with this widget >(I never used it before), but it is clear to me that this part of the Motif >code has *never* been tested by the dev team :-( Unfortunately, the first bug wouldn't have been found by testing on our reference platforms which, like many machines, silently ignore attempts to free unmalloc'ed memory... I can make these fixes, and fixes to several memory leaks in the FileSB, available to full support holders. As Ron said, the 1.1 FileSB has been thoroughly revamped, and these bugs (and the memory leaks) are no more. There are now no bugs in FileSB. There are now no bugs in FileSB. There are now no bugs in FileSB. (what I say three times is true) -- David Brooks dbrooks@osf.org Systems Engineering, OSF uunet!osf.org!dbrooks