comp.lang.ada
 help / color / mirror / Atom feed
* Vads X/Motif & C
@ 1996-09-10  0:00 Mark Bell
  1996-09-11  0:00 ` Brian Crouch
                   ` (2 more replies)
  0 siblings, 3 replies; 5+ messages in thread
From: Mark Bell @ 1996-09-10  0:00 UTC (permalink / raw)




Folks --

I'm attempting to interface Ada with an X/Motif government 
application written in C.  I'm using Vads Ada (V6.2.3) and 
Vads Ada X Interface to Motif (V3.2.3) The platform is a 
Sparcstation 20 running Solaris 2.4.

Initially I had dynamic allocation problems due to the
ways Vads and Solaris were performing memory allocation.
I believe I have this solved by modifying the v_usr_confb.a file
to use malloc() instead of sbrk() in the kernel allocation
function V_KRN_ALLOC_CALLOUT.  After this was done, I no
longer get segmentation faults after malloc calls in the
government C software.

However, I'm still getting segmentation faults during various
X/Motif calls, and I'm not 100 percent sure that the above
fix has totally addressed the problem of the interaction of the
Vads Ada runtime and Solaris OS in regards to memory allocation.
Does anyone have any "lessons learned" from doing similar work ??

I'm also running in problems such as getting a resource's value 
from a widget, then immediately setting the widget's resource to
the same value, and getting a segmentation fault.  For Example:

Xt.Xt_Resource_Management.Xt_Set_Arg(
  Arg => An_Arg_List(0),
  Name => Xt_Stringdefs.Xt_N_background,
  Value => blank_color'Address);

Xt.Xt_Resource_Management.Xt_Get_Values(
  W    => Presentation_Drawing_Area,
  Args => An_Arg_List(0..0));

Xt.Xt_Resource_Management.Xt_Set_Values(
   W    => Presentation_Drawing_Area,
   Args => An_Arg_List(0..0));

(Segmentation fault occurs)

Any suggestions as to why this happens ??

Thanks





Mark S. Bell                           412-268-7925 (Voice)
Software Engineering Institute         412-268-5758 (Fax)
Carnegie Mellon University             ** These are my opinions, 
4500 Fifth Ave, Pittsburgh PA.,15213      not those of the SEI or CMU **




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Vads X/Motif & C
  1996-09-10  0:00 Vads X/Motif & C Mark Bell
@ 1996-09-11  0:00 ` Brian Crouch
  1996-09-12  0:00 ` Frank Petranka
  1996-09-12  0:00 ` Sandy McPherson
  2 siblings, 0 replies; 5+ messages in thread
From: Brian Crouch @ 1996-09-11  0:00 UTC (permalink / raw)



Mark Bell wrote, in part:
> 
> However, I'm still getting segmentation faults during various
> X/Motif calls, and I'm not 100 percent sure that the above
> fix has totally addressed the problem of the interaction of the
> Vads Ada runtime and Solaris OS in regards to memory allocation.
> Does anyone have any "lessons learned" from doing similar work ??
>

Does your program use tasking?  If so, you should try increasing the 
task storage space by using the 'STORAGE_SIZE attribute on the task 
type.  The default task storage space in my Sun Ada environment 
(which should be the same as your Vads) is only 10K which can 
quickly be eaten up in a Motif program.




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Vads X/Motif & C
  1996-09-10  0:00 Vads X/Motif & C Mark Bell
  1996-09-11  0:00 ` Brian Crouch
  1996-09-12  0:00 ` Frank Petranka
@ 1996-09-12  0:00 ` Sandy McPherson
  2 siblings, 0 replies; 5+ messages in thread
From: Sandy McPherson @ 1996-09-12  0:00 UTC (permalink / raw)
  To: Mark Bell


Mark Bell wrote:
> 
> Folks --
> 
snip...
> I believe I have this solved by modifying the v_usr_confb.a file
> to use malloc() instead of sbrk() in the kernel allocation
> function V_KRN_ALLOC_CALLOUT.  After this was done, I no
> longer get segmentation faults after malloc calls in the
> government C software.
> 

Motif uses XtMalloc and so should all applications written using Xt. You
may find that stuff allocated by Motif cannot be freed using free().Try
changing the thing to use XtMalloc and then do a #define in the C code
to get it to use XtMalloc as well,maybe this will work.. No promises
though

> Xt.Xt_Resource_Management.Xt_Set_Arg(
>   Arg => An_Arg_List(0),
>   Name => Xt_Stringdefs.Xt_N_background,
>   Value => blank_color'Address);
> 
> Xt.Xt_Resource_Management.Xt_Get_Values(
>   W    => Presentation_Drawing_Area,
>   Args => An_Arg_List(0..0));
> 
> Xt.Xt_Resource_Management.Xt_Set_Values(
>    W    => Presentation_Drawing_Area,
>    Args => An_Arg_List(0..0));
> 
> (Segmentation fault occurs)
> 
> Any suggestions as to why this happens ??
> 
Yup!

consider the equivalent in C

XtSetArg( arg_list[0], XtNbackground, &colour );
XtGetValues( w, arg_list, 1 );
XtSetValues( w, arg_list, 1 );

Oh dear! you've just set the pixel value of the background colour to a
pointer to colour!!!!

The correct thingy in C is

XtSetArg( arg_list[0], XtNbackground, &colour );
XtGetValues( w, arg_list, 1 );
XtSetArg( arg_list[0], XtNbackground, colour );
XtSetValues( w, arg_list, 1 );

This is because C needs to be able to write into the area given by the
address of colour on the get, but can take the value directly from
colour on the set. The solution in Ada is therefere that you cannot use
the 'ADDRESS in the set operation....

Xt.Xt_Resource_Management.Xt_Set_Arg(
  Arg => An_Arg_List(0),
  Name => Xt_Stringdefs.Xt_N_background,
  Value => blank_color);

should work...

Motif, Xt, X11 and Ada are not a good mixture in my experience, as the
API is too dependent on the concepts common in C and (rightly) alien to
Ada. In my experience it is usually easier to call Ada from C than vice
versa, so I prefer to control the GUI using C code and write my actual
application in Ada, the danger here is the temptation to to more than
widget mangling in the C code, which can lead to disaster. If you
restrict your C code to extracting stuff from the widgets and passing it
to Ada and extracting stuff from Ada and passing it to the widgets, you
shouldn't come to any harm and you will retain your sanity- which will
be severely tried once you try to handle the null terminated strings
which Motif demands directly in Ada (before everybody jumps on me, I
know you can do it, but it drove me nuts). If you are worried about
mis-use of C then use lint religiously or better still get QAC and
Purify (or tools of that ilk, I believe there are some good ones from
GNU).

hope this helps.... 
-- 
Sandy McPherson	MBCS CEng.	tel: 	+31 71 565 4288 (w)
ESTEC/WAS
P.O. Box 299
NL-2200AG Noordwijk




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Vads X/Motif & C
  1996-09-10  0:00 Vads X/Motif & C Mark Bell
  1996-09-11  0:00 ` Brian Crouch
@ 1996-09-12  0:00 ` Frank Petranka
  1996-09-12  0:00 ` Sandy McPherson
  2 siblings, 0 replies; 5+ messages in thread
From: Frank Petranka @ 1996-09-12  0:00 UTC (permalink / raw)




On 10 Sep 1996, Mark Bell wrote:

> 
> Folks --
> 
> I'm attempting to interface Ada with an X/Motif government 
> application written in C.  I'm using Vads Ada (V6.2.3) and 
> Vads Ada X Interface to Motif (V3.2.3) The platform is a 
> Sparcstation 20 running Solaris 2.4.
> 
> Initially I had dynamic allocation problems due to the
> ways Vads and Solaris were performing memory allocation.
> I believe I have this solved by modifying the v_usr_confb.a file
> to use malloc() instead of sbrk() in the kernel allocation
> function V_KRN_ALLOC_CALLOUT.  After this was done, I no
> longer get segmentation faults after malloc calls in the
> government C software.
> 
> However, I'm still getting segmentation faults during various
> X/Motif calls, and I'm not 100 percent sure that the above
> fix has totally addressed the problem of the interaction of the
> Vads Ada runtime and Solaris OS in regards to memory allocation.
> Does anyone have any "lessons learned" from doing similar work ??
> 
> I'm also running in problems such as getting a resource's value 
> from a widget, then immediately setting the widget's resource to
> the same value, and getting a segmentation fault.  For Example:
> 
> Xt.Xt_Resource_Management.Xt_Set_Arg(
>   Arg => An_Arg_List(0),
>   Name => Xt_Stringdefs.Xt_N_background,
>   Value => blank_color'Address);
> 
> Xt.Xt_Resource_Management.Xt_Get_Values(
>   W    => Presentation_Drawing_Area,
>   Args => An_Arg_List(0..0));
> 
> Xt.Xt_Resource_Management.Xt_Set_Values(
>    W    => Presentation_Drawing_Area,
>    Args => An_Arg_List(0..0));
> 
> (Segmentation fault occurs)
> 

I believe an Xt_Get_Values requires blank_color'address for Value while
an Xt_Set_Values requires blank_color for Value. 


Disclaimer: The views or opinions expressed in this article are of the user 
and do not, in any manner, reflect that of the Navy.

            Frank J. Petranka          Naval Surface Warfare Center
            (540)653-4849              Dahlgren, Va. 22448
                    fpetran@relay.nswc.navy.mil




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Vads X/Motif & C
@ 1996-09-13  0:00 Mark Bell
  0 siblings, 0 replies; 5+ messages in thread
From: Mark Bell @ 1996-09-13  0:00 UTC (permalink / raw)



Thanks to all who responded to my questions, either via private
email or this newsgroup.

Most of the suggestions I had already tried, but I was glad to
see that I was at least looking in the correct areas.  I've
done Ada for many years, but this is the first time I've had
to deal with X/Motif, let alone interfacing to it from Ada !

I can not change the malloc() calls to Xtmalloc() calls in the
C source code, as the C code is "off the shelf".  Even though
I have some of the source for reference, changing it is not
an option.

Several folks asked some further questions about my application.
The C code is from the U.S. Army, and is called TEM (Terrain Evaluation
Module V 9.3.1).  It consists of main program which spawns several
servers.  It comes with a C-based GUI interface.  As received,
the application and GUI seems to work fine on the Solaris platform.
(Can I infer that the malloc vs xtmalloc issue is not a problem
here, or that it just hasn't surfaced yet?  The C code does
use malloc).

We (at the SEI) have written a Convoy Planning Prototype in Ada 83.
This uses the VADS X/Motif interface.  The initial versions used 
a line map for Convoy routing purposes.  These versions run fine
on the Solaris platform.

We are attempting to replace the line map with the actual
geographical maps and accompying services offered by TEM.
Thus, we need to bypass the provided GUI and use our own.
This is where the problems are.

Concerning the following code segment
 
> Xt.Xt_Resource_Management.Xt_Set_Arg(
>   Arg => An_Arg_List(0),
>   Name => Xt_Stringdefs.Xt_N_background,
>   Value => blank_color'Address);
> 
> Xt.Xt_Resource_Management.Xt_Get_Values(
>   W    => Presentation_Drawing_Area,
>   Args => An_Arg_List(0..0));
> 
> Xt.Xt_Resource_Management.Xt_Set_Values(
>    W    => Presentation_Drawing_Area,
>    Args => An_Arg_List(0..0));
> 
> (Segmentation fault occurs)
> 
I was not surprised to see that it was such an obvious goof...
another case of not seeing the trees in the forest !  I wondered
why this was the only place that I had trouble with the
Xt_Set_Value function.

Thanks again...




Mark S. Bell                           412-268-7925 (Voice)
Software Engineering Institute         412-268-5758 (Fax)
Carnegie Mellon University             ** These are my opinions, 
4500 Fifth Ave, Pittsburgh PA.,15213      not those of the SEI or CMU **




^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~1996-09-13  0:00 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1996-09-10  0:00 Vads X/Motif & C Mark Bell
1996-09-11  0:00 ` Brian Crouch
1996-09-12  0:00 ` Frank Petranka
1996-09-12  0:00 ` Sandy McPherson
  -- strict thread matches above, loose matches on Subject: below --
1996-09-13  0:00 Mark Bell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox