[squeak-dev] Building (Linux) VM - with segfaults. that point to audio

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Building (Linux) VM - with segfaults. that point to audio

Brad Fuller-4
Objective: I'm trying to build the VM out of the box, nothing fancy. I
want to use ALSA.
Problem: I'm getting segfaults when playing any audio object (from the
Objects>Multimedia panel)

I svn'd fresh source from the trunk, and followed the directions in
README.SVN [1]. I then moved to unix subdir and made. Everything went
fine, no errors and installed fine. Squeak seems to run fine.e.g. I
exercised the network retrieving the Universe packages.

However, when I start up an image and pull out any of the audio
objects, a segfault happens immediately:

Segmentation fault

17753728 [] in >playLoop
17753820 [] in Semaphore>critical:
17753544 BlockContext>ensure:
17753360 Semaphore>critical:
17720844 >playLoop
17720660 [] in >startPlayerProcessBufferSize:rate:stereo:sound:
17720752 [] in BlockContext>newProcess
Aborted

I get the same segfault using a command option:
$ squeak -vm sound=ALSA Squeak3.10.2-7179-basic.image

If I specify "none":
$ squeak -vm sound=none Squeak3.10.2-7179-basic.image

then no segfault, and of course, no sounds.


the plugin does exist in the squeak directory:
$ lsa /usr/local/lib/squeak/3.10-4
total 22540
   4 drwxr-xr-x 2 root root     4096 2008-11-14 15:35 .
   4 drwxr-xr-x 5 1000 1000     4096 2008-11-14 15:32 ..
  28 -rwxr-xr-x 1 root root    26820 2008-11-14 15:32 AioPlugin
 172 -rwxr-xr-x 1 root root   170451 2008-11-14 15:32 B3DAcceleratorPlugin
  32 -rwxr-xr-x 1 root root    29332 2008-11-14 15:32 ClipboardExtendedPlugin
  76 -rwxr-xr-x 1 root root    71250 2008-11-14 15:32 DBusPlugin
  24 -rwxr-xr-x 1 root root    20934 2008-11-14 15:32 FileCopyPlugin
 184 -rwxr-xr-x 1 root root   182395 2008-11-14 15:32 GStreamerPlugin
  32 -rwxr-xr-x 1 root root    32161 2008-11-14 15:32 ImmX11Plugin
  88 -rwxr-xr-x 1 root root    85971 2008-11-14 15:32 KedamaPlugin
 140 -rwxr-xr-x 1 root root   138507 2008-11-14 15:32 KedamaPlugin2
  44 -rwxr-xr-x 1 root root    44065 2008-11-14 15:32 MIDIPlugin
 792 -rwxr-xr-x 1 root root   803221 2008-11-14 15:32 Mpeg3Plugin
  24 -rwxr-xr-x 1 root root    23088 2008-11-14 15:32 npsqueak.so
  36 -rwxr-xr-x 1 root root    36765 2008-11-14 15:32 PseudoTTYPlugin
 144 -rwxr-xr-x 1 root root   142582 2008-11-14 15:32 RomePlugin
2472 -rwxr-xr-x 1 root root  2525072 2008-11-14 15:32 squeak
 208 -rwxr-xr-x 1 root root   205337 2008-11-14 15:32 Squeak3D
17200 -rw-r--r-- 1 root root 17584742 2008-11-14 15:35 SqueakV39.sources
 116 -rwxr-xr-x 1 root root   113755 2008-11-14 15:32 UnixOSProcessPlugin
  20 -rwxr-xr-x 1 root root    17974 2008-11-14 15:32 UUIDPlugin
 100 -rwxr-xr-x 1 root root    96184 2008-11-14 15:32 VideoForLinuxPlugin
 112 -rwxr-xr-x 1 root root   110434 2008-11-14 15:32 vm-display-fbdev
  28 -rwxr-xr-x 1 root root    26121 2008-11-14 15:32 vm-display-null
 272 -rwxr-xr-x 1 root root   271778 2008-11-14 15:32 vm-display-X11
  56 -rwxr-xr-x 1 root root    49985 2008-11-14 15:32 vm-sound-ALSA
  20 -rwxr-xr-x 1 root root    16870 2008-11-14 15:32 vm-sound-null
  84 -rwxr-xr-x 1 root root    79461 2008-11-14 15:32 vm-sound-OSS
  28 -rwxr-xr-x 1 root root    25109 2008-11-14 15:32 XDisplayControlPlugin

I thought maybe it was because SoundPlugin was not there, but it's in:
 $ ls src/vm/intplugins/SoundPlugin
SoundPlugin.c

and:
$ cat src/plugins.int
# Automatically generated makefile include for internal plugins
INTERNAL_PLUGINS = ADPCMCodecPlugin AsynchFilePlugin
BMPReadWriterPlugin B2DPlugin BitBltPlugin CroquetPlugin DSAPrims
ZipPlugin DropPlugin FFTPlugin FilePlugin FloatArrayPlugin
FloatMathPlugin GeniePlugin JPEGReadWriter2Plugin JPEGReaderPlugin
JoystickTabletPlugin Klatt LargeIntegers LocalePlugin Matrix2x3Plugin
MiscPrimitivePlugin RePlugin SecurityPlugin SerialPlugin SocketPlugin
SoundCodecPrims SoundGenerationPlugin SoundPlugin StarSqueakPlugin
SurfacePlugin

I assume it got built and is located internally in the vm proper.

Any ideas? I have a feeling I just missed something completely easy in
the setup.
Or, could this be because I'm running 64bit? Since everything else is working?


[1] the first instruction in README.SVN is incorrect. It should be: $
svn co http://squeakvm.org/svn/squeak/trunk squeak - .i.e. the path is
a bit wrong. Perhaps I should write up a bug?

(should these types of messages go to the squeak-vm list? I long-ago
unsubscribed to that since it had little traffic)

--
Brad Fuller

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Building (Linux) VM - with segfaults. that point to audio

Tim Johnson

On Nov 14, 2008, at 6:56 PM, Brad Fuller wrote:

> I assume it got built and is located internally in the vm proper.
>
> Any ideas? I have a feeling I just missed something completely easy in
> the setup.
> Or, could this be because I'm running 64bit? Since everything else  
> is working?

Brad,

Just a completely random hunch, but have you checked to make sure that  
Squeak is outputting audio at the same frequency (44.1 kHz or 48 kHz)  
that your Linux audio setup is set to?  I apologize that I don't have  
more specific information re: how to achieve this in your particular  
setup.  I know my Squeak VM crashed on OpenBSD because my audio  
hardware was running at I believe 22050 Hz and Squeak expected  
something different (e.g. 44100).

Cheers,
Tim J

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Building (Linux) VM - with segfaults. that point to audio

Brad Fuller-4
On Mon, Nov 17, 2008 at 12:13 PM, Tim Johnson <[hidden email]> wrote:

>
> On Nov 14, 2008, at 6:56 PM, Brad Fuller wrote:
>
>> I assume it got built and is located internally in the vm proper.
>>
>> Any ideas? I have a feeling I just missed something completely easy in
>> the setup.
>> Or, could this be because I'm running 64bit? Since everything else is
>> working?
>
> Brad,
>
> Just a completely random hunch, but have you checked to make sure that
> Squeak is outputting audio at the same frequency (44.1 kHz or 48 kHz) that
> your Linux audio setup is set to?  I apologize that I don't have more
> specific information re: how to achieve this in your particular setup.  I
> know my Squeak VM crashed on OpenBSD because my audio hardware was running
> at I believe 22050 Hz and Squeak expected something different (e.g. 44100).

That's strange that you had a crash because of that. My ALSA setup
should accommodate any change, though. I've played all kinds of audio
at different sample rates. I'll check, though.

I think what I have to do is check out what role vm-sound-ALSA plays.
I haven't had a chance yet. I hope to get to that today.
sqUnixSoundALSA.c does get built (it shows up in
platforms/unix/bld/vm-sound-ALSA/sqUnixSoundALSA.o




--
Brad Fuller

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Building (Linux) VM - with segfaults. that point to audio

Brad Fuller-4
I'm not any further, but this is what I've found:

I seem to get the segfault it SoundPlayer>>playLoop at:

                        self primSoundPlaySamples: count from: Buffer startingAt: 1.

But, I don\' know really where to go from here. I checked out
SoundPlugin and sqUnixSoundALSA.c
and they both have the function:

  int snd_PlaySamplesFromAtLength(int frameCount, int arrayIndex, int
startIndex)

which I assume is what is being called from Squeak.

When I run 'configure', the audio section that is sent to the terminal
looks correct:

checking for Advanced Linux Sound Architecture... yes
checking for Mac OS X CoreAudio... no
******** disabling vm-sound-MacOSX
checking for Network Audio System... no
******** disabling vm-sound-NAS
checking for Advanced Linux Sound Architecture... yes
checking for SunOS/Solaris audio... no
******** disabling vm-sound-Sun
checking for custom sound support... no
******** disabling vm-sound-custom

(don't know why ALSA is mentioned twice, though.)

Here's the segfault again:

Segmentation fault

20547312 [] in >playLoop
20547404 [] in Semaphore>critical:
20547220 BlockContext>ensure:
20547128 Semaphore>critical:
20515212 >playLoop
20515028 [] in >startPlayerProcessBufferSize:rate:stereo:sound:
20515120 [] in BlockContext>newProcess
Aborted

BTW, it didn't matter when I changed the sample rate to 44100, still
had the segfault.

I don't know where to turn from here, short of compiling with debug
flag on and starting up gdb.
Any ideas much appreciated. If someone knows the architecture of what
happens when the primitive is called and what should happen in the
ALSA plugin code that could be helpful.

thanks for reading!


--
Brad Fuller

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Building (Linux) VM - with segfaults. that point to audio

johnmci
GDB is your friend.

PlaySamplesFromAtLength
is where we take the bytes from squeak and write them to the  
platform's sound logic. In this case for
sqUnixSoundALSA.c
the code is below

You need to confirm startIndex, output_channels, output_handle,  
samples are all sane. In debugging past issue with
the sound API I can say we don't consider if the parms can be bogus as  
a result of attempting to drive
the sound primitives when we haven't really setup the sound logic  
properly.

static sqInt  sound_PlaySamplesFromAtLength(sqInt frameCount, sqInt  
arrayIndex, sqInt startIndex)
{
   if (output_handle)
     {
       void *samples= (void *)arrayIndex + startIndex *  
output_channels * 2;
       int   count=   snd_pcm_writei(output_handle, samples,  
frameCount);
       if (count < frameCount / 2)
        {
          output_buffer_frames_available= 0;
        }
       if (count < 0)
        {
          if (count == -EPIPE)    /* underrun */
            {
              int err;
              snd(pcm_prepare(output_handle), "sound_PlaySamples:  
snd_pcm_prepare");
              return 0;
            }
          fprintf(stderr, "snd_pcm_writei returned %i\n", count);
          return 0;
        }
       return count;
     }
   success(false);
   return 0;
}



On 17-Nov-08, at 3:02 PM, Brad Fuller wrote:

> I'm not any further, but this is what I've found:
>
> I seem to get the segfault it SoundPlayer>>playLoop at:
>
> self primSoundPlaySamples: count from: Buffer startingAt: 1.
>
> But, I don\' know really where to go from here. I checked out
> SoundPlugin and sqUnixSoundALSA.c
> and they both have the function:
>
>  int snd_PlaySamplesFromAtLength(int frameCount, int arrayIndex, int
> startIndex)
>
> which I assume is what is being called from Squeak.
>
> When I run 'configure', the audio section that is sent to the terminal
> looks correct:
>
> checking for Advanced Linux Sound Architecture... yes
> checking for Mac OS X CoreAudio... no
> ******** disabling vm-sound-MacOSX
> checking for Network Audio System... no
> ******** disabling vm-sound-NAS
> checking for Advanced Linux Sound Architecture... yes
> checking for SunOS/Solaris audio... no
> ******** disabling vm-sound-Sun
> checking for custom sound support... no
> ******** disabling vm-sound-custom
>
> (don't know why ALSA is mentioned twice, though.)
>
> Here's the segfault again:
>
> Segmentation fault
>
> 20547312 [] in >playLoop
> 20547404 [] in Semaphore>critical:
> 20547220 BlockContext>ensure:
> 20547128 Semaphore>critical:
> 20515212 >playLoop
> 20515028 [] in >startPlayerProcessBufferSize:rate:stereo:sound:
> 20515120 [] in BlockContext>newProcess
> Aborted
>
> BTW, it didn't matter when I changed the sample rate to 44100, still
> had the segfault.
>
> I don't know where to turn from here, short of compiling with debug
> flag on and starting up gdb.
> Any ideas much appreciated. If someone knows the architecture of what
> happens when the primitive is called and what should happen in the
> ALSA plugin code that could be helpful.
>
> thanks for reading!
>
>
> --
> Brad Fuller
>

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================




Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Building (Linux) VM - with segfaults. that point to audio

Brad Fuller-4
Thanks for the reply, John.

Yeah, I know what THAT code looks like.. it's only my speculation that
the Squeak primitive is calling this function.  My first question was
does "primSoundPlaySamples"  _directly_ call PlaySamplesFromLength in
the ALSA c code? Or, put a better way, how do I tell which smalltalk
method calls which c code function? Is there a table of pointers
somewhere? (sorry, I might have known this before, but I can't
remember and I don't know where this is on the wiki. But, after I send
this msg I'm looking for it again.)

Yeah, the args look correct in Squeak. This is an unmodified image, so
I assume there shouldn't be any problem there. I guess I have to fire
up gdb and see if the args are really correct at that stage. Just was
hoping that someone would tell me that I didn't set up configure
correctly for the make -- or that I missed something in the confugure
to include ALSA in the build. ( I just have the feeling that the ALSA
code is not being executed.,, i.e. it's not a bug in ALSA, but it's
going into the weeds... well. obviously it's going into the weeds, but
not because of ALSA code)


On Mon, Nov 17, 2008 at 3:40 PM, John M McIntosh
<[hidden email]> wrote:

> GDB is your friend.
>
> PlaySamplesFromAtLength
> is where we take the bytes from squeak and write them to the platform's
> sound logic. In this case for
> sqUnixSoundALSA.c
> the code is below
>
> You need to confirm startIndex, output_channels, output_handle, samples are
> all sane. In debugging past issue with
> the sound API I can say we don't consider if the parms can be bogus as a
> result of attempting to drive
> the sound primitives when we haven't really setup the sound logic properly.
>
> static sqInt  sound_PlaySamplesFromAtLength(sqInt frameCount, sqInt
> arrayIndex, sqInt startIndex)
> {
>  if (output_handle)
>    {
>      void *samples= (void *)arrayIndex + startIndex * output_channels * 2;
>      int   count=   snd_pcm_writei(output_handle, samples, frameCount);
>      if (count < frameCount / 2)
>        {
>          output_buffer_frames_available= 0;
>        }
>      if (count < 0)
>        {
>          if (count == -EPIPE)    /* underrun */
>            {
>              int err;
>              snd(pcm_prepare(output_handle), "sound_PlaySamples:
> snd_pcm_prepare");
>              return 0;
>            }
>          fprintf(stderr, "snd_pcm_writei returned %i\n", count);
>          return 0;
>        }
>      return count;
>    }
>  success(false);
>  return 0;
> }
>
>
>
> On 17-Nov-08, at 3:02 PM, Brad Fuller wrote:
>
>> I'm not any further, but this is what I've found:
>>
>> I seem to get the segfault it SoundPlayer>>playLoop at:
>>
>>                        self primSoundPlaySamples: count from: Buffer
>> startingAt: 1.
>>
>> But, I don\' know really where to go from here. I checked out
>> SoundPlugin and sqUnixSoundALSA.c
>> and they both have the function:
>>
>>  int snd_PlaySamplesFromAtLength(int frameCount, int arrayIndex, int
>> startIndex)
>>
>> which I assume is what is being called from Squeak.
>>
>> When I run 'configure', the audio section that is sent to the terminal
>> looks correct:
>>
>> checking for Advanced Linux Sound Architecture... yes
>> checking for Mac OS X CoreAudio... no
>> ******** disabling vm-sound-MacOSX
>> checking for Network Audio System... no
>> ******** disabling vm-sound-NAS
>> checking for Advanced Linux Sound Architecture... yes
>> checking for SunOS/Solaris audio... no
>> ******** disabling vm-sound-Sun
>> checking for custom sound support... no
>> ******** disabling vm-sound-custom
>>
>> (don't know why ALSA is mentioned twice, though.)
>>
>> Here's the segfault again:
>>
>> Segmentation fault
>>
>> 20547312 [] in >playLoop
>> 20547404 [] in Semaphore>critical:
>> 20547220 BlockContext>ensure:
>> 20547128 Semaphore>critical:
>> 20515212 >playLoop
>> 20515028 [] in >startPlayerProcessBufferSize:rate:stereo:sound:
>> 20515120 [] in BlockContext>newProcess
>> Aborted
>>
>> BTW, it didn't matter when I changed the sample rate to 44100, still
>> had the segfault.
>>
>> I don't know where to turn from here, short of compiling with debug
>> flag on and starting up gdb.
>> Any ideas much appreciated. If someone knows the architecture of what
>> happens when the primitive is called and what should happen in the
>> ALSA plugin code that could be helpful.
>>
>> thanks for reading!
>>
>>
>> --
>> Brad Fuller
>>
>
> --
> ===========================================================================
> John M. McIntosh <[hidden email]>
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ===========================================================================
>
>
>
>
>



--
Brad Fuller

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Building (Linux) VM - with segfaults. that point to audio

johnmci
primitiveSoundPlaySamples
primSoundPlaySamples
invokes
primitiveSoundPlaySamples
which calls
framesPlayed = snd_PlaySamplesFromAtLength(frameCount, (int)buf,  
startIndex - 1);
which is the platform specific api for playing sound  (frameCount) at  
buf starting at (startIndex -1)
on unix it's really snd->snd_PlaySamplesFromAtLength
so it dispatchs to the sound plugin for the unix's VM choice.


On 17-Nov-08, at 4:12 PM, Brad Fuller wrote:

> Thanks for the reply, John.
>
> Yeah, I know what THAT code looks like.. it's only my speculation that
> the Squeak primitive is calling this function.  My first question was
> does "primSoundPlaySamples"  _directly_ call PlaySamplesFromLength in
> the ALSA c code? Or, put a better way, how do I tell which smalltalk
> method calls which c code function? Is there a table of pointers
> somewhere? (sorry, I might have known this before, but I can't
> remember and I don't know where this is on the wiki. But, after I send
> this msg I'm looking for it again.)
>
> Yeah, the args look correct in Squeak. This is an unmodified image, so
> I assume there shouldn't be any problem there. I guess I have to fire
> up gdb and see if the args are really correct at that stage. Just was
> hoping that someone would tell me that I didn't set up configure
> correctly for the make -- or that I missed something in the confugure
> to include ALSA in the build. ( I just have the feeling that the ALSA
> code is not being executed.,, i.e. it's not a bug in ALSA, but it's
> going into the weeds... well. obviously it's going into the weeds, but
> not because of ALSA code)

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================




Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Building (Linux) VM - with segfaults. that point to audio

Derek O'Connell-2
In reply to this post by Brad Fuller-4
Hi Brad,

"playLoop" is used with a semaphore if
SoundPlayer>>primSoundStartBufferSize:rate:stereo:semaIndex: returns
without error. Otherwise "oldStylePlayLoop" is used with a delay instead
of the semaphore. Without debug info I cannot say for certain what the
problem is but you might want to change
SoundPlayer>>primSoundStartBufferSize:rate:stereo:semaIndex: so it skips
the actual call to the primitive, which will force the use of the
oldStylePlayloop, and see if this gets you any where.

Put some printf() statements in the C-code for quick debug info or see
if there is "strace" for your platform. If you intend to do more coding
at this level then gdb will probably save you a lot time in future.

HTH

DMOC

Brad Fuller wrote:

> I'm not any further, but this is what I've found:
>
> I seem to get the segfault it SoundPlayer>>playLoop at:
>
> self primSoundPlaySamples: count from: Buffer startingAt: 1.
>
> But, I don\' know really where to go from here. I checked out
> SoundPlugin and sqUnixSoundALSA.c
> and they both have the function:
>
>   int snd_PlaySamplesFromAtLength(int frameCount, int arrayIndex, int
> startIndex)
>
> which I assume is what is being called from Squeak.
>
> When I run 'configure', the audio section that is sent to the terminal
> looks correct:
>
> checking for Advanced Linux Sound Architecture... yes
> checking for Mac OS X CoreAudio... no
> ******** disabling vm-sound-MacOSX
> checking for Network Audio System... no
> ******** disabling vm-sound-NAS
> checking for Advanced Linux Sound Architecture... yes
> checking for SunOS/Solaris audio... no
> ******** disabling vm-sound-Sun
> checking for custom sound support... no
> ******** disabling vm-sound-custom
>
> (don't know why ALSA is mentioned twice, though.)
>
> Here's the segfault again:
>
> Segmentation fault
>
> 20547312 [] in >playLoop
> 20547404 [] in Semaphore>critical:
> 20547220 BlockContext>ensure:
> 20547128 Semaphore>critical:
> 20515212 >playLoop
> 20515028 [] in >startPlayerProcessBufferSize:rate:stereo:sound:
> 20515120 [] in BlockContext>newProcess
> Aborted
>
> BTW, it didn't matter when I changed the sample rate to 44100, still
> had the segfault.
>
> I don't know where to turn from here, short of compiling with debug
> flag on and starting up gdb.
> Any ideas much appreciated. If someone knows the architecture of what
> happens when the primitive is called and what should happen in the
> ALSA plugin code that could be helpful.
>
> thanks for reading!
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Building (Linux) VM - with segfaults. that point to audio

José Luis Redrejo
Brad, a silly question: are you using a 64 bits linux? I'm asking because your symptoms are exactly as those of http://bugs.squeak.org/view.php?id=7103

Regards
José L.


2008/11/18 Derek O'Connell <[hidden email]>
Hi Brad,

"playLoop" is used with a semaphore if SoundPlayer>>primSoundStartBufferSize:rate:stereo:semaIndex: returns without error. Otherwise "oldStylePlayLoop" is used with a delay instead of the semaphore. Without debug info I cannot say for certain what the problem is but you might want to change SoundPlayer>>primSoundStartBufferSize:rate:stereo:semaIndex: so it skips the actual call to the primitive, which will force the use of the oldStylePlayloop, and see if this gets you any where.

Put some printf() statements in the C-code for quick debug info or see if there is "strace" for your platform. If you intend to do more coding at this level then gdb will probably save you a lot time in future.

HTH

DMOC


Brad Fuller wrote:
I'm not any further, but this is what I've found:

I seem to get the segfault it SoundPlayer>>playLoop at:

                       self primSoundPlaySamples: count from: Buffer startingAt: 1.

But, I don\' know really where to go from here. I checked out
SoundPlugin and sqUnixSoundALSA.c
and they both have the function:

 int snd_PlaySamplesFromAtLength(int frameCount, int arrayIndex, int
startIndex)

which I assume is what is being called from Squeak.

When I run 'configure', the audio section that is sent to the terminal
looks correct:

checking for Advanced Linux Sound Architecture... yes
checking for Mac OS X CoreAudio... no
******** disabling vm-sound-MacOSX
checking for Network Audio System... no
******** disabling vm-sound-NAS
checking for Advanced Linux Sound Architecture... yes
checking for SunOS/Solaris audio... no
******** disabling vm-sound-Sun
checking for custom sound support... no
******** disabling vm-sound-custom

(don't know why ALSA is mentioned twice, though.)

Here's the segfault again:

Segmentation fault

20547312 [] in >playLoop
20547404 [] in Semaphore>critical:
20547220 BlockContext>ensure:
20547128 Semaphore>critical:
20515212 >playLoop
20515028 [] in >startPlayerProcessBufferSize:rate:stereo:sound:
20515120 [] in BlockContext>newProcess
Aborted

BTW, it didn't matter when I changed the sample rate to 44100, still
had the segfault.

I don't know where to turn from here, short of compiling with debug
flag on and starting up gdb.
Any ideas much appreciated. If someone knows the architecture of what
happens when the primitive is called and what should happen in the
ALSA plugin code that could be helpful.

thanks for reading!






Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Building (Linux) VM - with segfaults. that point to audio

Brad Fuller-4
On Tue, Nov 18, 2008 at 7:29 AM, José Luis Redrejo <[hidden email]> wrote:
> Brad, a silly question: are you using a 64 bits linux? I'm asking because
> your symptoms are exactly as those of
> http://bugs.squeak.org/view.php?id=7103

Not a silly question, I mentioned that I'm using 64bits in my original
message. Thanks for the confirmation.
I've traced the problem to these two lines in this function:

==
static sqInt  sound_PlaySamplesFromAtLength(sqInt frameCount, sqInt
arrayIndex, sqInt startIndex)
{
 if (output_handle)
   {
     void *samples= (void *)arrayIndex + startIndex * output_channels * 2;
     int   count=   snd_pcm_writei(output_handle, samples, frameCount);
==

I have to recompile to optimize out  to see what's going on (thought I
did that). But, maybe someone could understand the problem by just
looking at this.Maybe it's an int size, or similar, problem.

sqMemoryAccess.h defines:

#if defined(SQ_IMAGE32)
 typedef int sqInt;
 typedef unsigned int usqInt;
#elif defined(SQ_HOST64)
 typedef long sqInt;
 typedef unsigned long usqInt;
#else
# if (SIZEOF_LONG_LONG != 8)
#   error long long integers are not 64-bits wide?
# endif
 typedef long long sqInt;
 typedef unsigned long long usqInt;
#endif

--
Brad Fuller


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Building (Linux) VM - with segfaults. that point to audio

Brad Fuller-4
The problem might be that arrayIndex is 32bit and it is used to
calculate *samples which is 64bit. This would be a problem if
arrayIndex has bit31 set.

EXAMPLE: If arrayIndex comes in with bit31 set (e.g. 0x911f13fc),
which is negative, the top bit is extended when *samples is
calculated. samples becomes 0xffffffff911f13fc.(actual values while
debugging)

Perhaps the cast (void *)arrayIndex was to fix that.

Here's the function... I'm referencing lines 5 and 6 of the function:

====================
1 static sqInt  sound_PlaySamplesFromAtLength(sqInt frameCount, sqInt
arrayIndex, sqInt startIndex)
2 {
3  if (output_handle)
4    {
5      void *samples= (void *)arrayIndex + startIndex * output_channels * 2;
6      int   count=   snd_pcm_writei(output_handle, samples, frameCount);
7      if (count < frameCount / 2)
8 {
9  output_buffer_frames_available= 0;
        }
      if (count < 0)
        {
          if (count == -EPIPE)    /* underrun */
            {
              int err;
              snd(pcm_prepare(output_handle), "sound_PlaySamples: snd_pcm_prepare");
              return 0;
            }
          fprintf(stderr, "snd_pcm_writei returned %i\n", count);
          return 0;
        }
      return count;
    }
  success(false);
============


Does that seem right to you all?

Maybe sqInt never gets to be long long?  sqMemoryAccess.h defines:

#if defined(SQ_IMAGE32)
 typedef int sqInt;
 typedef unsigned int usqInt;
#elif defined(SQ_HOST64)
 typedef long sqInt;
 typedef unsigned long usqInt;
#else
# if (SIZEOF_LONG_LONG != 8)
#   error long long integers are not 64-bits wide?
# endif
 typedef long long sqInt;
 typedef unsigned long long usqInt;
#endif


--
Brad Fuller

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Building (Linux) VM - with segfaults. that point to audio

Brad Fuller-4
On Tue, Nov 18, 2008 at 10:22 AM, Brad Fuller <[hidden email]> wrote:

> The problem might be that arrayIndex is 32bit and it is used to
> calculate *samples which is 64bit. This would be a problem if
> arrayIndex has bit31 set.
>
> EXAMPLE: If arrayIndex comes in with bit31 set (e.g. 0x911f13fc),
> which is negative, the top bit is extended when *samples is
> calculated. samples becomes 0xffffffff911f13fc.(actual values while
> debugging)
>
> Perhaps the cast (void *)arrayIndex was to fix that.
>
> Here's the function... I'm referencing lines 5 and 6 of the function:
>
> ====================
> 1 static sqInt  sound_PlaySamplesFromAtLength(sqInt frameCount, sqInt
> arrayIndex, sqInt startIndex)
> 2 {
> 3  if (output_handle)
> 4    {
> 5      void *samples= (void *)arrayIndex + startIndex * output_channels * 2;
> 6      int   count=   snd_pcm_writei(output_handle, samples, frameCount);
> 7      if (count < frameCount / 2)
> 8       {
> 9         output_buffer_frames_available= 0;
>        }
>      if (count < 0)
>        {
>          if (count == -EPIPE)    /* underrun */
>            {
>              int err;
>              snd(pcm_prepare(output_handle), "sound_PlaySamples: snd_pcm_prepare");
>              return 0;
>            }
>          fprintf(stderr, "snd_pcm_writei returned %i\n", count);
>          return 0;
>        }
>      return count;
>    }
>  success(false);
> ============
>
>
> Does that seem right to you all?
>
> Maybe sqInt never gets to be long long?  sqMemoryAccess.h defines:
>
> #if defined(SQ_IMAGE32)
>  typedef int sqInt;
>  typedef unsigned int usqInt;
> #elif defined(SQ_HOST64)
>  typedef long sqInt;
>  typedef unsigned long usqInt;
> #else
> # if (SIZEOF_LONG_LONG != 8)
> #   error long long integers are not 64-bits wide?
> # endif
>  typedef long long sqInt;
>  typedef unsigned long long usqInt;
> #endif


oh... I should add I see warnings during compilation. This is applicable:

platforms/unix/vm-sound-ALSA/sqUnixSoundALSA.c: In function
'sound_PlaySamplesFromAtLength':
platforms/unix/vm-sound-ALSA/sqUnixSoundALSA.c:204: warning: cast to
pointer from integer of different size

Line 204 in this error is line 5 above

--
Brad Fuller

Reply | Threaded
Open this post in threaded view
|

Re: [Vm-dev] Re: [squeak-dev] Building (Linux) VM - with segfaults. that point to audio

Brad Fuller-4
In reply to this post by Brad Fuller-4
On Thu, Nov 20, 2008 at 3:17 PM, Brad Fuller <[hidden email]> wrote:
> On Wed, Nov 19, 2008 at 4:19 AM, David T. Lewis <[hidden email]> wrote:
>> You can get a VMMaker with SlangBrowser support from SqueakSource.
>> VMMaker-dtl.107 would be the most recent in that branch.
>
> Where can I find VMMaker 107? I only see 106 on SqueakSource

Also, how does one use the SlangBrowser? I don't see it anywhere.

I also don't think that the vm-sound-ALSA C code was generated from
Slang. I can't seem to locate it, so I assume that it was generated
outside of Squeak. Can anyone (Ian?) confirm this?


--
Brad Fuller

Reply | Threaded
Open this post in threaded view
|

Re: [Vm-dev] Re: [squeak-dev] Building (Linux) VM - with segfaults. that point to audio

David T. Lewis
On Thu, Nov 20, 2008 at 03:58:08PM -0800, Brad Fuller wrote:
> On Thu, Nov 20, 2008 at 3:17 PM, Brad Fuller <[hidden email]> wrote:
>
> Also, how does one use the SlangBrowser? I don't see it anywhere.

Find the far-right button on a class browser, where is says "source".
Click on that and select "translate inlined C" or "translate to C".
Or you can evaluate "FilePlugin asCString".

  http://wiki.squeak.org/squeak/5916

> I also don't think that the vm-sound-ALSA C code was generated from
> Slang. I can't seem to locate it, so I assume that it was generated
> outside of Squeak. Can anyone (Ian?) confirm this?

Correct, it is not generated. Ian wrote it.

Dave