Primitive failed in: AbtCodePageConverter>>#primOpenConvertTo:from: due to OS error1

Hi there,

after spending a few days on a very complex feature, I am now fighting against Unicode.
It seems part of my problems is the following error when I try to convert from one code page to another:

Primitive failed in: AbtCodePageConverter>>#primOpenConvertTo:from: due to OS error1

I am getting there from this message send:

(AbtCodePageConverter current
            convert: 'erlöse'
            fromCodePage: (AbtAbstractCodePageConverter codePageFromCharacterSet: 'UTF-8')
            toCodePage: (AbtCodePageConverter currentCodePage))
                trimNull.

This snippet runs nicely on a local Linux machine (details below) but not on our headless production server.

I've seen that Marten had this very same error 8 years ago: http://forums.instantiations.com/topic-12-1200.html , but it seems it never got solved.

The funny thing is that I only get this error on our production server (Ubuntu 12.04 LTS 64 bit), and not on a local Ubuntu VM (13.10 32 bit). So I guess this has to do with some libraries that are missing.

abtprc86.so is present in the VAST runtime directory, its file permissions are okay.

So what can I do to find the exact reason for this error? What libraries are used by abtprc86.so?

The runtime directory on that production server is just the decompressed Server runtime zip, while on the local dev machine we're using a development install of VAST.

Any help is greatly appreciated - this affects our production system...

Joachim

I think I am one step further:

iconv_open is a function that is found in glibc. So my guess would be my image/vm on the 64 bit linux machine cannot find the 32 bit version of libc.so.

Here is the output of locate libc.so on the server:

/lib/i386-linux-gnu/libc.so.6
/lib/x86_64-linux-gnu/libc.so.6

I guess the first one is the 32 bit version (I have ia-32libs installed on that box, otherwise VAST and other programs wouldn't even start).

So I thought I try to add /lib/i386-linux-gnu to the LD_LIBRARY_PATH in the abt startup shell script. But it didn't help. Also, just adding /lib didn't help.

Does anybody have an idea how I can continue from here?
How do I find out whether this theory is true anyways? (Maybe I should se an OS Error 126 if that was the problem)

Joachim

I also tried exporting the GCONV_PATH in the abt shell script pointing it to the folder where the 32-bit gconv objects are located. To no avail.

And one more piece to the puzzle. It seems the problem is not that the libc. is not found:

Joachim -

Hi John,

On Wednesday, June 4, 2014 7:40:37 AM UTC-7, Joachim Tuchel wrote:

Nevertheless, since I could make it work on the local 32 bit Linux dev machine, I'd be interested to know why it doesn't work on the 64 bit Ubuntu machine. In the meantime, I am quite sure this is not a VAST problem but a configuration problem of the production server, but I'd like to find out how I can dig down and find the cause.

Joachim

Almost exactly one year has passed, and I came full circle back to this problem.

This time, however, I cannot influence what I get from the web browser, so I need to convert ISO-8859-1 to UTF-8 and back.
My code runs perfectly on a windows machine, but I get this Primitve Failed OS Error 1 on Ubuntu 14.04 64 Bits.

Any hints or tips are greatly appreciated!

Joachim


 

Am Mittwoch, 4. Juni 2014 16:40:37 UTC+2 schrieb Joachim Tuchel:

Hi John,

UNIX is even worse than Windows when it comes to inscrutable system errors. OS Error 1 is EPERM which means "you can't do that".

Sounds good ;-)

 

What does AbtCodePageConverter currentCodePage answer in development time and in run time?

On the windows dev machine I get 819

On both Linux machines I get 'ISO-8859-1'

During my search I found that I initially had the wrong codepage on the production server, but that is now changed. I still get 'You can't do that' however.

Once again I wrote a Javascript plugin to navigate around this problem. I escape the text to send up to the server ob the javascript side and this works.

The negative drawback of this is that what was first implemented in 2 lines of Seaside code (and worked on Windows) took me more than a day to implement on the javascript side because I had some troubles with Associative Arrays and my individual learning curve... So to put it in a positive way: I learned a lot from this.

Nevertheless, since I could make it work on the local 32 bit Linux dev machine, I'd be interested to know why it doesn't work on the 64 bit Ubuntu machine. In the meantime, I am quite sure this is not a VAST problem but a configuration problem of the production server, but I'd like to find out how I can dig down and find the cause.

Joachim

So I found the old thread that was mentioned here: http://ibm.software.vasmalltalk.narkive.com/dVbKQaS6/va6-0-4-iconv-open-fails-with-os-error-1-all-utf-8-code-page-conversions-broken

Back then (8 years ago) the problem could be solved by replacing abtprc60.so with an older version, because the new one was "broken".

So it seems at least once back in history, there was a working solution for the UTF-8 conversion stuff in VAST on Linux.

Any ideas?


Am Freitag, 22. Mai 2015 20:03:14 UTC+2 schrieb Joachim Tuchel:

Almost exactly one year has passed, and I came full circle back to this problem.

This time, however, I cannot influence what I get from the web browser, so I need to convert ISO-8859-1 to UTF-8 and back.
My code runs perfectly on a windows machine, but I get this Primitve Failed OS Error 1 on Ubuntu 14.04 64 Bits.

Any hints or tips are greatly appreciated!

Joachim


 

Am Mittwoch, 4. Juni 2014 16:40:37 UTC+2 schrieb Joachim Tuchel:

Hi John,

UNIX is even worse than Windows when it comes to inscrutable system errors. OS Error 1 is EPERM which means "you can't do that".

Sounds good ;-)

 

What does AbtCodePageConverter currentCodePage answer in development time and in run time?

On the windows dev machine I get 819

On both Linux machines I get 'ISO-8859-1'

During my search I found that I initially had the wrong codepage on the production server, but that is now changed. I still get 'You can't do that' however.

Once again I wrote a Javascript plugin to navigate around this problem. I escape the text to send up to the server ob the javascript side and this works.

The negative drawback of this is that what was first implemented in 2 lines of Seaside code (and worked on Windows) took me more than a day to implement on the javascript side because I had some troubles with Associative Arrays and my individual learning curve... So to put it in a positive way: I learned a lot from this.

Nevertheless, since I could make it work on the local 32 bit Linux dev machine, I'd be interested to know why it doesn't work on the 64 bit Ubuntu machine. In the meantime, I am quite sure this is not a VAST problem but a configuration problem of the production server, but I'd like to find out how I can dig down and find the cause.

Joachim

Interesting...

I replaced

convertFromCodePage: 65001

with

convertFromCodePage: 'UTF-8'

and the PrimitiveFailed is gone, even on the production (64 bit) machine.

... and using

'ÄÖÜ' convertFromCodePage: 'ISO-8859-1' toCodePage: 'UTF-8'

the Primiteve error is back on Ubuntu 14.04.2 (64 bit), while on our test VM (Ubunu 13.10 (32 bit)), the code snippet works in an image.

So it seems what I urgently need is help digging into this problem.

Does anybody know where I can start digging, what tools to use and what to do to find out what's missing on the 64 bit machine??? I am pretty sure this is not a Smalltalk problem, but a Linux problem, because it runs on 32 bits in an image. I am downloading Kubuntu 14.04 64 bits in order to set up a 64 bit test VM

Thanks

Joachim




Am Freitag, 22. Mai 2015 21:42:03 UTC+2 schrieb Joachim Tuchel:

Interesting...

I replaced

convertFromCodePage: 65001

with

convertFromCodePage: 'UTF-8'

and the PrimitiveFailed is gone, even on the production (64 bit) machine.