PR# 12603 Compiling class with external routine crashes estudio

Compiling a class with an external routine causes estudio to crash.
Compiling the same system with the command line compiler works fine.
It is clear from the trace that this is not a compiler problem.

Start estudio and compile with attached class and .ecf file.  Estudio
crashes with the attached trace.

I have confirmed that the crash no longer occurs on Solaris x86, in either
the C Output panel or the Console panel, whether the Locale is "Unselected"
or some specific locale.  Closing report.

I reimplemented a little in encoding library the way of checking convertibility. But I was not able to produce the crash. I fixed this by the information you provided and tested on FC and FreeBSD, it worked well. Also protections are added in the Output tools.
I believe this has been fixed, in rev#69056.
Can you confirm, if possible, on your machine? Thanks.

The list of entries in directory /usr/lib/locale is attached as locale.txt.
Directory /usr/shared/i18n/locales does not seem to exist on this machine.

Thanks for the information. Your test1.c indeed printed the error on Solaris, OK on other Unix OS (I tried FC and FreeBSD). I need to find a solution for this. Can you send me the list of entries in /usr/lib/locale. And also /usr/shared/i18n/locales if you have.

One final piece of information:  the crash for running an external command or
for freezing a system and launching C compilations does not occur if the
Locale is "Unselected".  If it is "English (United States)", then the crash
does occur.  Perhaps this explains why it doesn't crash on Solaris SPARC,
since I think the Locale there was "Unselected".

Apparently, I do have UTF-16 available on this machine (Solaris 10 on x86).
As the attached C program shows, a call to iconv_open with identical "to" and
"from" arguments fails with errno 22 (meaning that the conversion is not
available).  But a conversion from "ISO8859-1" to "UTF-16" (or vice versa)
is valid (iconv_open returns a valid descriptor instead of -1).  So it appears
that the method of passing the same codeset as both "to" and "from" arguments
to determine if that codeset is present does not work on Solaris.

However, this same behavior occurs on Solaris SPARC, so now I don't understand
why Solaris SPARC external commands do not fail.

I'm not the expert for the encoding stuff, but Ted will have a look at it.
Thanks for the precise description.

I managed to compile a workbench version of ec and run "ec -bench" under the
debugger.  When I ran the external command "echo hi", I got a precondition
violation.  Here's what I found as I explored:

1. {EB_EXTERNAL_OUTPUT_TOOL}.process_text_block calls `output_text.append_text'
   and passes it a Void reference, which violates the precondition of
   `append_text'.

2. The Void is produced by a call to

      source_encoding.convert_to (destination_encoding, str)

   Source encoding is ISO8859-1.
   Destination encoding is UTF-16.

3. {ENCODING}.convert_to is fails to do the conversion and is correctly
   setting `last_conversion_successful' to False, but the caller is not
   checking this boolean.

4. {ENCODING}.convert_to calls {ENCODING}.is_valid, which returns False.

5. {ENCODING_IMP}.is_code_page_valid is called with argument "UTF-16"
   and it returns False.  This routine calls `is_codeset_convertable,
   which just calls iconv_open, passing pointers to "UTF-16" as the "to"
   a
....
Output truncated, Click download to get the full message

I could not reproduce it at all. On my Solaris x86-64 I only have access to russian, german, chinese and unselected. In all of them, it does not crash at all.

If you have a workbench version, can you provide us the actual string that is being converted?

It is still reproducible every time.  It does not have anything to do with
C compilation.  It seems to be related to running another process from within
estudio on Solaris x86 (32-bit or 64-bit).  I have never seen it on
Solaris SPARC.

Another way to reproduce it every time is to switch to the External Output
tab.  The Locale field says "English (United States)".  In Command field,
type "echo hi" and click on the Start Command button.  In fact, you can type
anything into the Command field (such as "xxx") and click Start Command and
it still crashes with the same trace, every time.

I tried Locale "French" and it still crashed.
I tried Locale "Unselected" and it did not crash!

This should give you enough clues to solve it.  Let me know if you need
more information.

I could not reproduce this. It must be because something in the output window triggers some warnings with some strange unicode characters. If you can still reproduce it, could you provide the output of the C compilation (run from outside the environment since it is crashing), the output of `locale' and the flags you use to compile the C code.

Attachments for problem report #12603