Smalltalk › Instantiations

[8.5.2 / Linux] VMTrap.log

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

16 messages Options

jtuchel

[8.5.2 / Linux] VMTrap.log

Hi there,

I am trying to call some DLL functions. In Windows, all is fine, on Linux (Ubuntu 32bit) I get no comment and a closed image. All I can find afterwards is the following vmtrap.log and an accompanying vmtrap.img...

I can see in the logfile of the called dll that the function finishes with a return code as expected, so it seems there are some problems after the DLL call finishes. How do I continue with my search for the error?

Any help is appreciated

Joachim

-Platform Information-------------------
VM Timestamp: 4.0,(NC) 8/7/2012 (84)
CPU Architecture: x86
OS Type: Linux
OS Version: 3.2.0-33-generic-pae
-State Information----------------------
Handler=0xb74d9b1c
vmState=0x00000000
vmError=0x00000034
Signal=0x0000000b
GS=0x00000033
FS=0x00000000
ES=0x0000007b
DS=0x0000007b
EDI=0x00000007
ESI=0xbf88ce90
EBP=0x00000000
ESP=0xbf88cd4c
EAX=0x00000000
EBX=0x00000000
ECX=0xb7304440
EDX=0xbf88cc78
TRAPNO=0x0000000e
ERR=0x00000004
EIP=0xb74fd959
CS=0x00000073
EFL=0x00210292
UESP=0xbf88cd4c
SS=0x0000007b
-----------------------------------------
Image snapshot: vmtrap.img
-Walkback--------------------------------
ERiCApi class>>Doit
EsCompiler class>>evaluate:for:warningLevel:onWarning:ifFail:
EsCompiler class>>evaluate:for:ifFail:
EtWindow>>evaluate:for:ifFail:
EtCodeWindow>>evaluateSelectionIn:ifFail:
[] in EmSystemConfiguration>>showBusyCursorWhile:
[] in EtWindow>>execShortOperation:
EtCodeWindow>>evaluateSelectionIn:ifFail:
[] in <optimized block> EtWindow>>menuEditInspect
[] in EmSystemConfiguration>>showBusyCursorWhile:
[] in <optimized block> EtWindow>>execShortOperation:
EtWindow>>menuEditInspect
[] in <optimized block> CwMenuPushButton>>dispatchTo:
CwMenu>>simpleCallback:clientData:callData:
CwRowColumn>>simpleCallback:clientData:callData:
[] in OrderedCollection>>do:
CwRowColumn>>simpleCallback:clientData:callData:
[] in <optimized block> OSWidget class>>simpleCallbackFor:clientData:callData:
XPlatformAdministration class>>readAndDispatch:allowIdle:allowEvents:allowCallbacks:
XPlatformAdministration class>>readAndDispatch
CwAppContext>>readAndDispatch
EsWindowSystemStartUp class>>messageLoop
UIProcess class>>forkUserInterface
[] in <optimized block> Process>>executeBlock:withArguments:
[] in Process>>executeBlock:withArguments:
[] in <optimized block> Process>>newProcessOn:stackSize:withArguments:named:

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/n69IV8Uhhq0J.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

jtuchel

Re: [8.5.2 / Linux] VMTrap.log

Okay, still having no luck with my callout.

Things I've tried so far

** strace -o strace.log ./abt
Shows nothing that I would consider problematic. Some ld.so files couldn't be found, but Google said nothing about this is worrying.

** Tried to find out if I was missing some libraries
ld.so is there (multiarch-support is installed)

** started the image with standard C locale
no change

** started the image without the -mcd switch
no change

** tried other calls to the same lib
same crash

Is there a list of libraries that VAST needs on Linux? Is there some strace switch that could help me find out which one may be missing (strace without any oiptions doesn't help)?

The only things I know for sure are:
* It is a General Protection Fault (Error 52)
* The called DLL does log its activity and return code, so t gets called, but then the image crashes
* The image quits with the above vmtrap.log and a vmtrap.img, which, according to some old post from John O'keefe on this forum, I cannot use for anything

Joachim

Am Montag, 19. November 2012 15:13:25 UTC+1 schrieb [hidden email]:

Hi there,

I am trying to call some DLL functions. In Windows, all is fine, on Linux (Ubuntu 32bit) I get no comment and a closed image. All I can find afterwards is the following vmtrap.log and an accompanying vmtrap.img...

I can see in the logfile of the called dll that the function finishes with a return code as expected, so it seems there are some problems after the DLL call finishes. How do I continue with my search for the error?

Any help is appreciated

Joachim

-Platform Information-------------------
VM Timestamp: 4.0,(NC) 8/7/2012 (84)
CPU Architecture: x86
OS Type: Linux
OS Version: 3.2.0-33-generic-pae
-State Information----------------------
Handler=0xb74d9b1c
vmState=0x00000000
vmError=0x00000034
Signal=0x0000000b
GS=0x00000033
FS=0x00000000
ES=0x0000007b
DS=0x0000007b
EDI=0x00000007
ESI=0xbf88ce90
EBP=0x00000000
ESP=0xbf88cd4c
EAX=0x00000000
EBX=0x00000000
ECX=0xb7304440
EDX=0xbf88cc78
TRAPNO=0x0000000e
ERR=0x00000004
EIP=0xb74fd959
CS=0x00000073
EFL=0x00210292
UESP=0xbf88cd4c
SS=0x0000007b
-----------------------------------------
Image snapshot: vmtrap.img
-Walkback--------------------------------
ERiCApi class>>Doit
EsCompiler class>>evaluate:for:warningLevel:onWarning:ifFail:
EsCompiler class>>evaluate:for:ifFail:
EtWindow>>evaluate:for:ifFail:
EtCodeWindow>>evaluateSelectionIn:ifFail:
[] in EmSystemConfiguration>>showBusyCursorWhile:
[] in EtWindow>>execShortOperation:
EtCodeWindow>>evaluateSelectionIn:ifFail:
[] in <optimized block> EtWindow>>menuEditInspect
[] in EmSystemConfiguration>>showBusyCursorWhile:
[] in <optimized block> EtWindow>>execShortOperation:
EtWindow>>menuEditInspect
[] in <optimized block> CwMenuPushButton>>dispatchTo:
CwMenu>>simpleCallback:clientData:callData:
CwRowColumn>>simpleCallback:clientData:callData:
[] in OrderedCollection>>do:
CwRowColumn>>simpleCallback:clientData:callData:
[] in <optimized block> OSWidget class>>simpleCallbackFor:clientData:callData:
XPlatformAdministration class>>readAndDispatch:allowIdle:allowEvents:allowCallbacks:
XPlatformAdministration class>>readAndDispatch
CwAppContext>>readAndDispatch
EsWindowSystemStartUp class>>messageLoop
UIProcess class>>forkUserInterface
[] in <optimized block> Process>>executeBlock:withArguments:
[] in Process>>executeBlock:withArguments:
[] in <optimized block> Process>>newProcessOn:stackSize:withArguments:named:

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/yUJ1SGgUypgJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

Louis LaBrunda

Re: [8.5.2 / Linux] VMTrap.log

Hi Joachim,

As you can tell from some of my recent posts, I have been playing with making some calls to windows DLLs. I know yours works on windows but not Linux. Anyway, over the course of many failures, I had what seemed to be success calling the DLL but things would blow up when Smalltalk tries to use or look at the results. Sometimes this would be trapped and I could keep working. I don't think I got a vmtrap but I did have times when the whole dev env just went away. I think these were caused by my bad structures with bad pointers in them, aka addressing problems.

Since you say the DLL seems to return okay, I would say you have all the required DLLs. Since you a get General Protection Fault (Error 52), I would guess that this is an addressing problem. Assuming the Linux DLLs are working correctly, maybe you don't have the correct privileges to access what they return.

This is a lot of guess work on my part, so it could be way off but I hope it helps.

Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/5x1aMjytcZAJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

Marten Feldtmann-2

Re: [8.5.2 / Linux] VMTrap.log

In reply to this post by jtuchel

WHERE do you see the information in your posted information, that the external call was successfull ?

Marten

Am Montag, 19. November 2012 15:13:25 UTC+1 schrieb [hidden email]:

I can see in the logfile of the called dll that the function finishes with a return code as expected, so it seems there are some problems after the DLL call finishes. How do I continue with my search for the error?

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/Ah-ROzqoGzwJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

jtuchel

Re: [8.5.2 / Linux] VMTrap.log

In reply to this post by Louis LaBrunda

Hi Lou,

hmm. As you say, the DLLs by the same vendor work well on Windows. But still I guess that doesn't necessarily mean that the linux libs also work. So I am in the vcery unpleasant position to have no idea who's to blame (well, most likely it is me, but you know what I mean ;-) ).

I guess if it were addressing problems, the windows calls would also fail, right?

In the meantime, I've also used ltrace to see what's going on and I asked questions on the vendor's support forums as well. So maybe someone there can help me debug a little deeper into the problem.

Joachim

Am Dienstag, 20. November 2012 15:59:04 UTC+1 schrieb Louis LaBrunda:

Hi Joachim,

As you can tell from some of my recent posts, I have been playing with making some calls to windows DLLs. I know yours works on windows but not Linux. Anyway, over the course of many failures, I had what seemed to be success calling the DLL but things would blow up when Smalltalk tries to use or look at the results. Sometimes this would be trapped and I could keep working. I don't think I got a vmtrap but I did have times when the whole dev env just went away. I think these were caused by my bad structures with bad pointers in them, aka addressing problems.

Since you say the DLL seems to return okay, I would say you have all the required DLLs. Since you a get General Protection Fault (Error 52), I would guess that this is an addressing problem. Assuming the Linux DLLs are working correctly, maybe you don't have the correct privileges to access what they return.

This is a lot of guess work on my part, so it could be way off but I hope it helps.

Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/3FV4gSft6rIJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

jtuchel

Re: [8.5.2 / Linux] VMTrap.log

In reply to this post by Marten Feldtmann-2

Marten,

you can't see it from anything in my post. The lib does write a log file that includes info on the call, up to the point of the return code (the full details that get logged on my windows machine for the very same call). Nothing is missing from that log file.

In the meantime I've not only tried strace but also ltrace and it seems the SIGSEGV occurs right after the last log. unfortunately, I cannot see whether it is the lib that crashes or the VAST VM. I'd like to find out, but don't know how I could do that. My knowlegde of gdb is practically zero, and I'm not sure if it would be the right tool for it.

I'll try installing the previous version of the lib (because the new one is just a few days old) and see whether that runs any better on linux.

Joachim

Am Dienstag, 20. November 2012 16:23:03 UTC+1 schrieb Marten Feldtmann:

WHERE do you see the information in your posted information, that the external call was successfull ?

Marten

Am Montag, 19. November 2012 15:13:25 UTC+1 schrieb [hidden email]:

I can see in the logfile of the called dll that the function finishes with a return code as expected, so it seems there are some problems after the DLL call finishes. How do I continue with my search for the error?

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/gR057Lrr7bMJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

jtuchel

Re: [8.5.2 / Linux] VMTrap.log

Hi again,

using openSuSE 12.2 32 bits shows the very exact behavior. So I really need to see if the older DLL works any better.

...and if not, I am out of ideas.

Joachim

Am Dienstag, 20. November 2012 19:01:44 UTC+1 schrieb [hidden email]:

Marten,

you can't see it from anything in my post. The lib does write a log file that includes info on the call, up to the point of the return code (the full details that get logged on my windows machine for the very same call). Nothing is missing from that log file.

In the meantime I've not only tried strace but also ltrace and it seems the SIGSEGV occurs right after the last log. unfortunately, I cannot see whether it is the lib that crashes or the VAST VM. I'd like to find out, but don't know how I could do that. My knowlegde of gdb is practically zero, and I'm not sure if it would be the right tool for it.

I'll try installing the previous version of the lib (because the new one is just a few days old) and see whether that runs any better on linux.

Joachim

Am Dienstag, 20. November 2012 16:23:03 UTC+1 schrieb Marten Feldtmann:
WHERE do you see the information in your posted information, that the external call was successfull ?

Marten

Am Montag, 19. November 2012 15:13:25 UTC+1 schrieb [hidden email]:

I can see in the logfile of the called dll that the function finishes with a return code as expected, so it seems there are some problems after the DLL call finishes. How do I continue with my search for the error?

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/el9J4SaCzyoJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

jtuchel

Re: [8.5.2 / Linux] VMTrap.log

So now I've tried something obvious: use the Smalltalk debugger to see what is going on:

The segfault occurs when I press INTO on the method including the primitive definition.

Does this definitely mean that the external library causes the crashes and not VAST?

The call has only one parameter: const char*, which I pass as aString asPSZ, and the exact same call works on Windows.

Or is there anything I can do to see whether control comes back to Smalltalk (even though I doubt it). I've used strace and ltrace, and I either am unable to understand their output or the info I am looking for is not in there...

Joachim

Am Dienstag, 20. November 2012 21:18:04 UTC+1 schrieb [hidden email]:

Hi again,

using openSuSE 12.2 32 bits shows the very exact behavior. So I really need to see if the older DLL works any better.

...and if not, I am out of ideas.

Joachim

Am Dienstag, 20. November 2012 19:01:44 UTC+1 schrieb [hidden email]:
Marten,

you can't see it from anything in my post. The lib does write a log file that includes info on the call, up to the point of the return code (the full details that get logged on my windows machine for the very same call). Nothing is missing from that log file.

In the meantime I've not only tried strace but also ltrace and it seems the SIGSEGV occurs right after the last log. unfortunately, I cannot see whether it is the lib that crashes or the VAST VM. I'd like to find out, but don't know how I could do that. My knowlegde of gdb is practically zero, and I'm not sure if it would be the right tool for it.

I'll try installing the previous version of the lib (because the new one is just a few days old) and see whether that runs any better on linux.

Joachim

Am Dienstag, 20. November 2012 16:23:03 UTC+1 schrieb Marten Feldtmann:
WHERE do you see the information in your posted information, that the external call was successfull ?

Marten

Am Montag, 19. November 2012 15:13:25 UTC+1 schrieb [hidden email]:

I can see in the logfile of the called dll that the function finishes with a return code as expected, so it seems there are some problems after the DLL call finishes. How do I continue with my search for the error?

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/KrK9TTL771oJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

Seth Berman

Re: [8.5.2 / Linux] VMTrap.log

Hi Joachim,

Have you tried building a small test in C that links to the lib and calls the function in question?

- Seth

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/h25kOZL_BLgJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

jtuchel

Re: [8.5.2 / Linux] VMTrap.log

Hi Seth,

the short answer: no

the long one: My C has rusted. I've done some C back in the last millennium and my Linux box is not prepared to do that.

But maybe I have to in order to prove to the library vendor that it's not my fault...

Joachim

Am Mittwoch, 21. November 2012 14:46:02 UTC+1 schrieb Seth Berman:

Hi Joachim,
Have you tried building a small test in C that links to the lib and calls the function in question?
- Seth

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/mzObeytLdb4J.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

jtuchel

Re: [8.5.2 / Linux] VMTrap.log

In reply to this post by jtuchel

Okay, one step further (or at least more effort put into the problem ;-) ):

This script:

|pruefer future |

pruefer := PlatformFunction callingConvention: 'c' function: 'MyFunctionName' library: 'theLibrary' parameterTypes: #(pointer) returnType: #uint32.

future := pruefer futureCallWith: 'someString' asPSZ.

future value

evaluates to an AcoError ACOEXCEPTIONHAPPENED (1008): Primitive failed due to general protection fault

Which doesn't really provide me with any new information, but at least the image continues to run and I can rerun the script a few times, just for the fun of it.

Does it prove to me that it's a problem with the external library?

Can I assume it is the library and not my environment?

My experiments with ltrace and strace do not give me any additional calories any more. I'm lost.

Joachim

Am Mittwoch, 21. November 2012 11:22:22 UTC+1 schrieb [hidden email]:

So now I've tried something obvious: use the Smalltalk debugger to see what is going on:

The segfault occurs when I press INTO on the method including the primitive definition.

Does this definitely mean that the external library causes the crashes and not VAST?
The call has only one parameter: const char*, which I pass as aString asPSZ, and the exact same call works on Windows.

Or is there anything I can do to see whether control comes back to Smalltalk (even though I doubt it). I've used strace and ltrace, and I either am unable to understand their output or the info I am looking for is not in there...

Joachim

Am Dienstag, 20. November 2012 21:18:04 UTC+1 schrieb [hidden email]:
Hi again,

using openSuSE 12.2 32 bits shows the very exact behavior. So I really need to see if the older DLL works any better.

...and if not, I am out of ideas.

Joachim

Am Dienstag, 20. November 2012 19:01:44 UTC+1 schrieb [hidden email]:
Marten,

you can't see it from anything in my post. The lib does write a log file that includes info on the call, up to the point of the return code (the full details that get logged on my windows machine for the very same call). Nothing is missing from that log file.

In the meantime I've not only tried strace but also ltrace and it seems the SIGSEGV occurs right after the last log. unfortunately, I cannot see whether it is the lib that crashes or the VAST VM. I'd like to find out, but don't know how I could do that. My knowlegde of gdb is practically zero, and I'm not sure if it would be the right tool for it.

I'll try installing the previous version of the lib (because the new one is just a few days old) and see whether that runs any better on linux.

Joachim

Am Dienstag, 20. November 2012 16:23:03 UTC+1 schrieb Marten Feldtmann:
WHERE do you see the information in your posted information, that the external call was successfull ?

Marten

Am Montag, 19. November 2012 15:13:25 UTC+1 schrieb [hidden email]:

I can see in the logfile of the called dll that the function finishes with a return code as expected, so it seems there are some problems after the DLL call finishes. How do I continue with my search for the error?

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/zA4y25veb_MJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

jtuchel

Re: [8.5.2 / Linux] VMTrap.log

In reply to this post by jtuchel

Hi Seth,

seems I have to become friends with the idea.

But to be sure I do the right thing: I guess I shouldn't statically link but use dlopen() to do exactly the same thing as VA ST, right?

Joachim

Am Mittwoch, 21. November 2012 15:24:25 UTC+1 schrieb [hidden email]:

Hi Seth,

the short answer: no

the long one: My C has rusted. I've done some C back in the last millennium and my Linux box is not prepared to do that.
But maybe I have to in order to prove to the library vendor that it's not my fault...

Joachim

Am Mittwoch, 21. November 2012 14:46:02 UTC+1 schrieb Seth Berman:
Hi Joachim,
Have you tried building a small test in C that links to the lib and calls the function in question?
- Seth

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/oAm4Cgej4lcJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

Seth Berman

Re: [8.5.2 / Linux] VMTrap.log

Hi Joachim,

Yes, you could do it that way. I think that is the way VAST would do it. I personally would start simple and just dynamically link the library during the linking process (i.e. gcc -o test test.o -lsharedLib)

Your approach works too, just a little more involved from the test standpoint since you have to control the linking manually.

I looked for a moment and found this tutorial...which should provide the scaffolding you need to perform the test

http://ehuss.net/shared/

On Wednesday, November 21, 2012 9:29:25 AM UTC-5, [hidden email] wrote:

Hi Seth,

seems I have to become friends with the idea.

But to be sure I do the right thing: I guess I shouldn't statically link but use dlopen() to do exactly the same thing as VA ST, right?

Joachim

Am Mittwoch, 21. November 2012 15:24:25 UTC+1 schrieb [hidden email]:
Hi Seth,

the short answer: no

the long one: My C has rusted. I've done some C back in the last millennium and my Linux box is not prepared to do that.
But maybe I have to in order to prove to the library vendor that it's not my fault...

Joachim

Am Mittwoch, 21. November 2012 14:46:02 UTC+1 schrieb Seth Berman:
Hi Joachim,
Have you tried building a small test in C that links to the lib and calls the function in question?
- Seth

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/uSgyJgT__2QJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

Louis LaBrunda

Re: [8.5.2 / Linux] VMTrap.log

In reply to this post by jtuchel

Hi Joachim,

From an earlier post:

I guess if it were addressing problems, the windows calls would also fail, right?

Maybe, but I'm wondering if in Linux there isn't some privilege required that in Windows you have or don't need.

Does it prove to me that it's a problem with the external library?
Can I assume it is the library and not my environment?

Unfortunately, I think the answer is no to both.

Also, should "...parameterTypes: #(pointer)..." be parameterTypes: #(#pointer)? Note the "#" for #pointer or is this just a typo in the post?

Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/1d8uwl9yus8J.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

jtuchel

Re: [8.5.2 / Linux] VMTrap.log

Lou.

thanks for your ideas.

Am Mittwoch, 21. November 2012 18:00:46 UTC+1 schrieb Louis LaBrunda:

Hi Joachim,

From an earlier post:

I guess if it were addressing problems, the windows calls would also fail, right?

Maybe, but I'm wondering if in Linux there isn't some privilege required that in Windows you have or don't need.

Okay, I had that thought for a moment also, but I wonder if that wouldn't keep the function in the library to execute and log something...

Does it prove to me that it's a problem with the external library?
Can I assume it is the library and not my environment?

Unfortunately, I think the answer is no to both.

I was really afraid of that answer...

Also, should "...parameterTypes: #(pointer)..." be parameterTypes: #(#pointer)? Note the "#" for #pointer or is this just a typo in the post?

I've tried changing to #(#pointer), but the result is the same. Inspecting the result of the two returns the same collection with a Symbol in it...

Joachim

Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/IBY358rcjg8J.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

jtuchel

Re: [8.5.2 / Linux] VMTrap.log

In reply to this post by Seth Berman

Hi Seth,

thanks for the link to this little tutorial. It is an excellent resource. I could tackle together a test program in C and compile it within an hour or so.

It helped me find out several things:

The library calls work in the C program wihtout any problems
If the program calls dlclose() right before the end, the program crashes with a segfault and the contents of its öogfile look exactly the same as if it was called with VA ST

So the question now is: does VA Smalltalk call dlclose (I guess the answer is yes)? And if so, is there anything wrong with calling dlclose (my guess would be no). If I'm guessing right, then the whole problem is not a VA Smalltalk problme but either a bug in the library or in my Linux environments...

Joachim

Am Mittwoch, 21. November 2012 16:17:50 UTC+1 schrieb Seth Berman:

Hi Joachim,

Yes, you could do it that way. I think that is the way VAST would do it. I personally would start simple and just dynamically link the library during the linking process (i.e. gcc -o test test.o -lsharedLib)

Your approach works too, just a little more involved from the test standpoint since you have to control the linking manually.

I looked for a moment and found this tutorial...which should provide the scaffolding you need to perform the test
http://ehuss.net/shared/

On Wednesday, November 21, 2012 9:29:25 AM UTC-5, [hidden email] wrote:
Hi Seth,

seems I have to become friends with the idea.

But to be sure I do the right thing: I guess I shouldn't statically link but use dlopen() to do exactly the same thing as VA ST, right?

Joachim

Am Mittwoch, 21. November 2012 15:24:25 UTC+1 schrieb [hidden email]:
Hi Seth,

the short answer: no

the long one: My C has rusted. I've done some C back in the last millennium and my Linux box is not prepared to do that.
But maybe I have to in order to prove to the library vendor that it's not my fault...

Joachim

Am Mittwoch, 21. November 2012 14:46:02 UTC+1 schrieb Seth Berman:
Hi Joachim,
Have you tried building a small test in C that links to the lib and calls the function in question?
- Seth

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/va-smalltalk/-/Xj-ahGGwjAwJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.