Smalltalk › Squeak › Squeak VM

Camera sig fault on 64 bits machines.

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

43 messages Options

123

Andreas Wacknitz

Re: Camera sig fault on 64 bits machines.

Hi Eliot,

Thanks again for your help.

Am 21.04.2014 um 22:56 schrieb Eliot Miranda <[hidden email]>:

Hi Andreas,

On Sat, Apr 19, 2014 at 2:52 PM, Andreas Wacknitz <[hidden email]> wrote:

Hi Eliot,

Today I was able to work on this problem again. Alas heartbeat_handler() in sqUnixTimerHeartbeat.c is not called automatically as it should be.
Only if I trigger an external ALRM signal (by means of signal -ALRM <pid>) it’s being called. I wasn’t able to find out how the trigger for it is being

set.

Hmmm. In sqUnixTimerHeartbeat.c::ioInitHeartbeat() there's a sigaction call that establishes heartbeat_handle as the handler for SIGALRM. Perhaps on FreeBSD or OpenSolaris you need to rearm the signal handler on each delivery? But perhaps there's a flag you can set in the sigaction that avoids having to do this.

No, when I trigger SIGALRM from the outside the image works (albeit very slow). First I emitted SIGALRM by means of kill -SIGALRM <pid> from the shell; later I wrote a simple C program to do that for me :)

The only place I found a nanosleep() call was in block() in sqUnixMain.c.

See the nanosleep in sqUnixHeartbeat.c::beatStateMachine.

Yeah, I don’t know how I could miss this. I will debug a little bit in order to find out why this doesn’t work as expected on OpenSolaris.

After the initial step through heartbeat, there won’t be any heartbeat_handler calls triggered from within the vm…

BTW what does with ticker and without ticker mean in respect to the heartbeat?

The Qwaq/Teleplace/Terf VM needs support for sound processing. The ticker is the thread or call that provides cycles for sound processing.

But look, if FreeBSD provides pthreads you should try and use sqUnixHeartbeat.c instead of sqUnixTimerHeartbeat.c.

I already did that yesterday. Alas it’s only working with superuser rights, otherwise I’ll get "pthread_setschedparam failed; consider using ITIMER_HEARTBEAT: Not owner“.

I will also investigate further here so maybe I will get this working.

HTH,
Eliot

Regards,

Andreas

Andreas Wacknitz

Re: Camera sig fault on 64 bits machines.

In reply to this post by Eliot Miranda-2

Hi again,

Am 21.04.2014 um 22:56 schrieb Eliot Miranda <[hidden email]>:

Hi Andreas,

On Sat, Apr 19, 2014 at 2:52 PM, Andreas Wacknitz <[hidden email]> wrote:

Hi Eliot,

Today I was able to work on this problem again. Alas heartbeat_handler() in sqUnixTimerHeartbeat.c is not called automatically as it should be.
Only if I trigger an external ALRM signal (by means of signal -ALRM <pid>) it’s being called. I wasn’t able to find out how the trigger for it is being

set.

Hmmm. In sqUnixTimerHeartbeat.c::ioInitHeartbeat() there's a sigaction call that establishes heartbeat_handle as the handler for SIGALRM. Perhaps on FreeBSD or OpenSolaris you need to rearm the signal handler on each delivery? But perhaps there's a flag you can set in the sigaction that avoids having to do this.

The only place I found a nanosleep() call was in block() in sqUnixMain.c.

See the nanosleep in sqUnixHeartbeat.c::beatStateMachine.

Now I have a clue why I didn’t see it before. If ITIMER_HEARTBEAT is set then all functionality is in sqUnixITimerHeartbeat.c and there is no nanosleep call there…

Regards,

Andreas

Eliot Miranda-2

Re: Camera sig fault on 64 bits machines.

In reply to this post by Andreas Wacknitz

On Tue, Apr 22, 2014 at 8:09 AM, Andreas Wacknitz <[hidden email]> wrote:

Hi Eliot,

Thanks again for your help.

Am 21.04.2014 um 22:56 schrieb Eliot Miranda <[hidden email]>:

Hi Andreas,

On Sat, Apr 19, 2014 at 2:52 PM, Andreas Wacknitz <[hidden email]> wrote:

Hi Eliot,

Today I was able to work on this problem again. Alas heartbeat_handler() in sqUnixTimerHeartbeat.c is not called automatically as it should be.
Only if I trigger an external ALRM signal (by means of signal -ALRM <pid>) it’s being called. I wasn’t able to find out how the trigger for it is being

set.

Hmmm. In sqUnixTimerHeartbeat.c::ioInitHeartbeat() there's a sigaction call that establishes heartbeat_handle as the handler for SIGALRM. Perhaps on FreeBSD or OpenSolaris you need to rearm the signal handler on each delivery? But perhaps there's a flag you can set in the sigaction that avoids having to do this.

No, when I trigger SIGALRM from the outside the image works (albeit very slow). First I emitted SIGALRM by means of kill -SIGALRM <pid> from the shell; later I wrote a simple C program to do that for me :)

The only place I found a nanosleep() call was in block() in sqUnixMain.c.

See the nanosleep in sqUnixHeartbeat.c::beatStateMachine.
Yeah, I don’t know how I could miss this. I will debug a little bit in order to find out why this doesn’t work as expected on OpenSolaris.

After the initial step through heartbeat, there won’t be any heartbeat_handler calls triggered from within the vm…

BTW what does with ticker and without ticker mean in respect to the heartbeat?

The Qwaq/Teleplace/Terf VM needs support for sound processing. The ticker is the thread or call that provides cycles for sound processing.

But look, if FreeBSD provides pthreads you should try and use sqUnixHeartbeat.c instead of sqUnixTimerHeartbeat.c.
I already did that yesterday. Alas it’s only working with superuser rights, otherwise I’ll get "pthread_setschedparam failed; consider using ITIMER_HEARTBEAT: Not owner“.

Ah, ok. That was the situation on linux before the 2.6.16 kernel (IIRC). I guess you're stuck with the getitimer heartbeat. So the issue is how to rearm the signal handler. If necessary put a call to signal/sigaction in heartbeat_handler.

I will also investigate further here so maybe I will get this working.

HTH,
Eliot

Regards,
Andreas

--
best,

Eliot

123