GNAT user-specified (via Raise_Exception) warning message size limit

GNAT user-specified (via Raise_Exception) warning message size limit

[marciant]

Hello,

Before I see about asking AdaCore directly via GNAT Tracker, I thought that I'd ask here first:

Is there a way to increase the default size limit of the exception message that is specified when calling Ada.Exceptions.Raise_Exception?

It seems that although quite long messages are accepted at calls to it, the message then retrieved and printed within a handler that uses Ada.Exceptions.Exception_Message on the occurrence only returns a truncated part of the original message - around the first 200 characters are returned and the rest is truncated.

Vincent Marciante

Re: GNAT user-specified (via Raise_Exception) warning message size limit

[Per Sandberg]

Well
 From a quick glance i would expect the answer to be:

In package System.Parameters update the value of
	"Default_Exception_Msg_Max_Length"  to a new value.
And recompile the run-times.

/P


Den 2018-02-16 kl. 19:44, skrev marciant@earthlink.net:
> Hello,
> 
> Before I see about asking AdaCore directly via GNAT Tracker, I thought that I'd ask here first:
> 
> Is there a way to increase the default size limit of the exception message that is specified when calling Ada.Exceptions.Raise_Exception?
> 
> It seems that although quite long messages are accepted at calls to it, the message then retrieved and printed within a handler that uses Ada.Exceptions.Exception_Message on the occurrence only returns a truncated part of the original message - around the first 200 characters are returned and the rest is truncated.
> 
> Vincent Marciante
> 

Re: GNAT user-specified (via Raise_Exception) warning message size limit

[marciant]

On Friday, February 16, 2018 at 1:59:17 PM UTC-5, Per Sandberg wrote:
> Well
>  From a quick glance i would expect the answer to be:
> 
> In package System.Parameters update the value of
> 	"Default_Exception_Msg_Max_Length"  to a new value.
> And recompile the run-times.
> 
> /P

Thanks.  I was hoping that there might be some "configuration" switch/pragma to do it.  However, if that ends up being the only way I guess that we would as for step by step from AdaCore or ask for a wavefront release.

(I'll have to read some more looking for a less "drastic" way before I ask to have the contact person ask Adacore.)

Vincent Marciante

Re: GNAT user-specified (via Raise_Exception) warning message size limit

[Anh Vo]

On Friday, February 16, 2018 at 11:11:26 AM UTC-8, marc...@earthlink.net wrote:
> On Friday, February 16, 2018 at 1:59:17 PM UTC-5, Per Sandberg wrote:
> > Well
> >  From a quick glance i would expect the answer to be:
> > 
> > In package System.Parameters update the value of
> > 	"Default_Exception_Msg_Max_Length"  to a new value.
> > And recompile the run-times.
> > 
> > /P
> 
> Thanks.  I was hoping that there might be some "configuration" switch/pragma to do it.  However, if that ends up being the only way I guess that we would as for step by step from AdaCore or ask for a wavefront release.
> 
> (I'll have to read some more looking for a less "drastic" way before I ask to have the contact person ask Adacore.)
 
I am curious to know the rationale for using pretty long exception message. I have not had a situation to use exception message this long in my software career.

Anh Vo

Re: GNAT user-specified (via Raise_Exception) warning message size limit

[marciant]

> I am curious to know the rationale for using pretty long exception message. I have not had a situation to use exception message this long in my software career.

Some XML text messages are being parsed "deep" down in a subsystem and when a problem is encountered a specific exception is raised and the problematic XML text is included in the exception message and propagated up a "level" or two of code where it is sometimes parsed again and repropagated with additional debugging information.  I know: "That is abuse of exceptions!" :)  However, it seemed to be (and proved to be) an easy and robust way to debug and provide forensic logs of problems that occurred in the fielded systems.

The project had been frozen as ObjectAda 7.2.2 however we are investigating the feasibility of moving to GNAT.  The ObjectAda compiler either did not have a size restriction or we luckily had not ever reached it!  Anyway, this seems to be the last sticking point before a simple proof-of-possibility can be demonstrated.  (I might first have to try to design some addition mechanism that can be utilized very much "under the covers" that allows the current architecture to remain mostly intact.)

Re: GNAT user-specified (via Raise_Exception) warning message size limit

[Randy Brukardt]

<marciant@earthlink.net> wrote in message 
news:789f6417-5e6f-4d5f-8abb-80246f4f405a@googlegroups.com...
...
>It seems that although quite long messages are accepted at calls to it, the
>message then retrieved and printed within a handler that uses
>Ada.Exceptions.Exception_Message on the occurrence only returns a
>truncated part of the original message - around the first 200 characters
>are returned and the rest is truncated.

For what it's worth, portable Ada code should not depend on exception 
messages longer than 200 characters, see RM 11.4.1(18).

For Janus/Ada, the truncation happens because an exception occurrence only 
has space for 200 characters. One could change the limited, but 
recompilation of the runtime clearly would be needed since it would change 
the definition/representation of the Exception_Occurrence type.

It sounds like GNAT is similar.

                                                 Randy.

Re: GNAT user-specified (via Raise_Exception) warning message size limit

[J-P. Rosen]

Le 17/02/2018 à 00:22, marciant@earthlink.net a écrit :
> Some XML text messages are being parsed "deep" down in a subsystem
> and when a problem is encountered a specific exception is raised and
> the problematic XML text is included in the exception message and
> propagated up a "level" or two of code where it is sometimes parsed
> again and repropagated with additional debugging information.
But why do you put all the message in the exception message?

Store it in some global structure, where you can handle it any way you
want. Note that it's what you'd do if you wanted to keep information
other than string (assuming you have no issue with concurrency, but then
you could use a task attribute)

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: GNAT user-specified (via Raise_Exception) warning message size limit

[marciant]

On Saturday, February 17, 2018 at 3:08:35 AM UTC-5, J-P. Rosen wrote:
> Le 17/02/2018 à 00:22, marc...@earthlink.net a écrit :
> > Some XML text messages are being parsed "deep" down in a subsystem
> > and when a problem is encountered a specific exception is raised and
> > the problematic XML text is included in the exception message and
> > propagated up a "level" or two of code where it is sometimes parsed
> > again and repropagated with additional debugging information.
> But why do you put all the message in the exception message?
> 
> Store it in some global structure, where you can handle it any way you
> want. Note that it's what you'd do if you wanted to keep information
> other than string (assuming you have no issue with concurrency, but then
> you could use a task attribute)

In the exception message for a few reasons:
- The information was always all text (an externally produced structured message)
- The final length was always unknown
- All debugging/logging "machinery" was originally designed to expect to only have to simply print out Exception_Information.
- For years it had all fit (including full/deep, explicit ObjectAda call trace back debugging information)
- Design for portability was never a requirement: The project was supposed to have been superseded a few times already by (non-Ada) projects that themselves ended up being cancelled.

However, like you suggested, I understand that using a global area (possibly indictated by "place-holder" text that is put in the exception message instead of the actual text) might be made to work with minimal disruption to the existing code.

Thanks,
Vincent Marciante

Re: GNAT user-specified (via Raise_Exception) warning message size limit

[Mark Lorenzen]

On Friday, February 16, 2018 at 8:11:26 PM UTC+1, marc...@earthlink.net wrote:
> On Friday, February 16, 2018 at 1:59:17 PM UTC-5, Per Sandberg wrote:
> > Well
> >  From a quick glance i would expect the answer to be:
> > 
> > In package System.Parameters update the value of
> > 	"Default_Exception_Msg_Max_Length"  to a new value.
> > And recompile the run-times.
> > 
> > /P
> 
> Thanks.  I was hoping that there might be some "configuration" switch/pragma to do it.  However, if that ends up being the only way I guess that we would as for step by step from AdaCore or ask for a wavefront release.
> 
> (I'll have to read some more looking for a less "drastic" way before I ask to have the contact person ask Adacore.)
> 
> Vincent Marciante

Don't hesitate to contact AdaCore with questions. They are very helpful and can also help you include the run-time in your own project, such that the run-time library is automatically rebuilt when you change it. I don't think a wavefront is the way forward for you - I think that learning to configure/change the run-time yourself and rebuilding it is very helpful. We do that ourselves and it's no big deal. But again, ask AdaCore.

Regards,

Mark L

Re: GNAT user-specified (via Raise_Exception) warning message size limit

[Simon Wright]

Mark Lorenzen <mark.lorenzen@gmail.com> writes:

> Don't hesitate to contact AdaCore with questions

That's what your organisation is paying for! and they like to get your
questions!

Re: GNAT user-specified (via Raise_Exception) warning message size limit

[briot.emmanuel]

> That's what your organisation is paying for! and they like to get your
> questions!

As a former AdaCore employee, I confirm they like to get questions from supported customers. After all, that's what helps contract renewal at the end of the year !

AdaCore has not always done a great job with unsupported customers, though. This is mostly because they already get so many new tickets every day (including the internally generated one, I think that must be around 60 a day or something -- given the relatively small size of the company and the time it takes to properly answer them, that's a lot).

But no report gets ignored in the end. For customer ones, there are plenty of scripts in place to catch unanswered requested. 

For unsupported customers, the initial reply might be of the kind "already fixed", in which case you can only wait for the next release, or "can't reproduce, we're closing", in which case it falls back to you to provide more details (this kind of message is in theory not sent to supported customers where a long dialog might take place to help AdaCore reproduce with the specific version of the compiler you use).

Once AdaCore has been able to reproduce the issue, bugs are generally fixed pretty fast, especially in the compiler (and I like to think in GNATCOLL and GPS while I was there :-) Enhancement requests are another story, since there's a fine balance between adding new features, and having to maintain them forever afterwards. Sometimes it takes a few similar reports until a general solution can be found, for instance.

Emmanuel

Re: GNAT user-specified (via Raise_Exception) warning message size limit

[marciant]

> Don't hesitate to contact AdaCore with questions. They are very helpful and can also help you include the run-time in your own project, such that the run-time library is automatically rebuilt when you change it. I don't think a wavefront is the way forward for you - I think that learning to configure/change the run-time yourself and rebuilding it is very helpful. We do that ourselves and it's no big deal. But again, ask AdaCore.
> 
> Regards,
> 
> Mark L

Thanks for the information regarding the ease of recompiling the the runtime.  I'll forward this to my manager. He wanted me to ask here before asking AdaCore.

Vincent Marciante

Re: GNAT user-specified (via Raise_Exception) warning message size limit

[marciant]

> Thanks for the information regarding the ease of recompiling the the runtime.  I'll forward this to my manager. He wanted me to ask here before asking AdaCore.


We contacted AdaCore and I'll eventually post the end result.

Re: GNAT user-specified (via Raise_Exception) warning message size limit

[marciant]

On Thursday, February 22, 2018 at 10:08:35 AM UTC-5, Vincent Marciante wrote:
> > Thanks for the information regarding the ease of recompiling the the runtime.  I'll forward this to my manager. He wanted me to ask here before asking AdaCore.
> 
> 
> We contacted AdaCore and I'll eventually post the end result.

The response was essentially: Not trivial on Windows; find a workaround instead.  

Re: GNAT user-specified (via Raise_Exception) warning message size limit

[Simon Wright]

marciant@earthlink.net writes:

> On Thursday, February 22, 2018 at 10:08:35 AM UTC-5, Vincent Marciante wrote:
>> > Thanks for the information regarding the ease of recompiling the
>> the runtime.  I'll forward this to my manager. He wanted me to ask
>> here before asking AdaCore.
>> 
>> 
>> We contacted AdaCore and I'll eventually post the end result.
>
> The response was essentially: Not trivial on Windows; find a
> workaround instead.

When (~2005) we had a problem with the runtime - we wanted to arrange
matters so that we could stream from our big-endian PowerPC target
(without changing the deliverable runtime) to our little-endian Windows
host machines - we were able to do the following (simple version):

* Copy the supplied s-strxdr.adb (now I see named s-stratt_xdr.adb) as
  s-stratt.adb to our own directory. This version streams data using
  eXternal Data Representation forms.

* Rebuild (with gnatmake) with the -a switch, which rebuilds the changed
  runtime unit(s) and any units which depend on them.

I don't remember asking AdaCore about this (though we were supported).

However, this cunning wheeze doesn't work with gprbuild.

As I recall, the Pro RTS came with a Makefile and instructions for
rebuilding the RTS. Perhaps things have changed.

Re: GNAT user-specified (via Raise_Exception) warning message size limit

[Mark Lorenzen]

On Thursday, February 22, 2018 at 9:27:31 PM UTC+1, Simon Wright wrote:
> 
> However, this cunning wheeze doesn't work with gprbuild.
> 
> As I recall, the Pro RTS came with a Makefile and instructions for
> rebuilding the RTS. Perhaps things have changed.

I don't know about the native run-times, but things have changed for bare-board targets.

Now you make a copy of the RTS, 'with' the copied RTS's project file in your own project file and point to the copied RTS using the project attribute Runtime (see http://docs.adacore.com/live/wave/gnat_ugx/html/gnat_ugx/gnat_ugx/specifying_the_run-time_library_and_target.html#selecting-the-run-time-library)

When you modify the copied RTS, it is automatically re-built as part of building your project as any other with'ed project. It's really easy.

Regards,

Mark L

Re: GNAT user-specified (via Raise_Exception) warning message size limit

[marciant]

On Thursday, February 22, 2018 at 3:27:31 PM UTC-5, Simon Wright wrote:
>...

Thanks for the detailed instructions.
However, having thought about how to do what you said,
a detail that I had not realize was critical came to mind:
The project actually depends on a precompiled library from
another organization _that_we_can_not_recompiled_by_us_!
So - probably obviously - the "adjust the runtime" "solution"
almost definitely would not be a possible solution at all! :-(
Right?

Therefore, as of now, I think that the only possible solution
is to adjust our code along the lines of the previous suggestions.

Thank you all for effort and help.

Vincent Marciante

Re: GNAT user-specified (via Raise_Exception) warning message size limit

[briot.emmanuel]

> * Rebuild (with gnatmake) with the -a switch, which rebuilds the changed
>   runtime unit(s) and any units which depend on them.
> 
> However, this cunning wheeze doesn't work with gprbuild.


As I am sure Simon already knows,  but might be useful for others (it doesn't
solve the problem highlighted by Simon, though):

You can actually use gprbuild to recompile locally the bodies of runtime files.
You just have to put them in your source directories, and change the
project file to make sure the file is compiled with -gnatg.
I have done that quite often for System.Memory

   project Default is
        package Compiler is
             for Switches ("s-memory.adb") use ("-gnatg");
        end Compiler;
   end Default;


This trick however doesn't work for specs, since it doesn't recompile
all runtime units that depend on them unless they are part of the project.
You might get away with creating a "runtime.gpr" project that uses for
source dirs the runtime location, and forces the -gnatg switch.

Emmanuel

Re: GNAT user-specified (via Raise_Exception) warning message size limit

[Simon Wright]

briot.emmanuel@gmail.com writes:

> As I am sure Simon already knows, but might be useful for others (it
> doesn't solve the problem highlighted by Simon, though):
>
> You can actually use gprbuild to recompile locally the bodies of
> runtime files.  You just have to put them in your source directories,
> and change the project file to make sure the file is compiled with
> -gnatg.  I have done that quite often for System.Memory
>
>    project Default is
>         package Compiler is
>              for Switches ("s-memory.adb") use ("-gnatg");
>         end Compiler;
>    end Default;

I don't think I've ever done this - failing to do it would explain why,
even after precompiling s-stratt.adb with -gnatpg (which gnatmake -a
did), gprbuild with the default .gpr wouldn't build.

> This trick however doesn't work for specs, since it doesn't recompile
> all runtime units that depend on them unless they are part of the
> project.  You might get away with creating a "runtime.gpr" project
> that uses for source dirs the runtime location, and forces the -gnatg
> switch.

I suppose other runtime units would need recompiling if any part of this
body was inlined.