On 3/30/2010 8:19 PM, John M McIntosh wrote:
Mac Carbon VM 4.2.3b1 sound recording busted
Must always remember to test (lot more) things after applying VMMaker changes. I'll have a 4.2.4b1 VM in a few days after some dust settles.
But for now if you hit the SoundRecorder record button in your squeak.image it will crash.
Oh dear. Same for Windows 4.0.1. Any ideas what's causing this?
Cheers, - Andreas
Eliot's change to the SoundPlugin primitiveSoundRecordSamplesInto altered the meaning of the bufSizeInBytes before the platform code would attempt to calculate the real size based on the startWordIndex, but his change moved that calculation into the plugin code, so without altering the platform code you end up doing a double subtraction of the startWordIndex offset.
In the carbon vm case this resulted in an underflow for an unsigned integer which then kills you when you say why yes there is 0xFFFFFAB bytes of storage to read into...
Based on his emal of "March 29, 2010 12:05:07 PM PDT" Likely there is still confusion about exactly how it should work and be fixed.
On 2010-03-30, at 8:56 PM, Andreas Raab wrote:
On 3/30/2010 8:19 PM, John M McIntosh wrote:
Mac Carbon VM 4.2.3b1 sound recording busted
Must always remember to test (lot more) things after applying VMMaker changes. I'll have a 4.2.4b1 VM in a few days after some dust settles.
But for now if you hit the SoundRecorder record button in your squeak.image it will crash.
Oh dear. Same for Windows 4.0.1. Any ideas what's causing this?
Cheers,
- Andreas
-- =========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
If the decisions is to roll back #primitiveSoundRecordSamplesInto:startingAt: to its previous implementation, then please also bump the version number in VMMaker class>>versionString to '4.0.2' at the same time. Thanks.
FWIW, my vote would be: Roll back #primitiveSoundRecordSamplesInto:startingAt: and add a method comment explaining that platform support is responsible for doing the subtraction.
Dave
On Tue, Mar 30, 2010 at 10:33:36PM -0700, John M McIntosh wrote:
Eliot's change to the SoundPlugin primitiveSoundRecordSamplesInto altered the meaning of the bufSizeInBytes before the platform code would attempt to calculate the real size based on the startWordIndex, but his change moved that calculation into the plugin code, so without altering the platform code you end up doing a double subtraction of the startWordIndex offset.
In the carbon vm case this resulted in an underflow for an unsigned integer which then kills you when you say why yes there is 0xFFFFFAB bytes of storage to read into...
Based on his emal of "March 29, 2010 12:05:07 PM PDT" Likely there is still confusion about exactly how it should work and be fixed.
On 2010-03-30, at 8:56 PM, Andreas Raab wrote:
On 3/30/2010 8:19 PM, John M McIntosh wrote:
Mac Carbon VM 4.2.3b1 sound recording busted
Must always remember to test (lot more) things after applying VMMaker changes. I'll have a 4.2.4b1 VM in a few days after some dust settles.
But for now if you hit the SoundRecorder record button in your squeak.image it will crash.
Oh dear. Same for Windows 4.0.1. Any ideas what's causing this?
Cheers,
- Andreas
On 3/31/2010 5:03 AM, David T. Lewis wrote:
If the decisions is to roll back #primitiveSoundRecordSamplesInto:startingAt: to its previous implementation, then please also bump the version number in VMMaker class>>versionString to '4.0.2' at the same time. Thanks.
I took the liberty to move the implementation forward instead of backwards, meaning that the primitive does the offset computation and calls the support code always with an offset of ZERO. So unless the support code screws up the straight default case, it'll work fine.
[BTW, I do think that's the way to deal with this stuff in general. Pass a simple pointer+length pair to the support code and have the extra stuff be done in the primitive. This ensures that the offset computations are done consistently and that the poor platform maintainer has a straight API to use]
John, if you could verify that this fixes the Mac crashes I'd appreciate it. I've tried on Windows and it works fine.
Cheers, - Andreas
FWIW, my vote would be: Roll back #primitiveSoundRecordSamplesInto:startingAt: and add a method comment explaining that platform support is responsible for doing the subtraction.
Dave
On Tue, Mar 30, 2010 at 10:33:36PM -0700, John M McIntosh wrote:
Eliot's change to the SoundPlugin primitiveSoundRecordSamplesInto altered the meaning of the bufSizeInBytes before the platform code would attempt to calculate the real size based on the startWordIndex, but his change moved that calculation into the plugin code, so without altering the platform code you end up doing a double subtraction of the startWordIndex offset.
In the carbon vm case this resulted in an underflow for an unsigned integer which then kills you when you say why yes there is 0xFFFFFAB bytes of storage to read into...
Based on his emal of "March 29, 2010 12:05:07 PM PDT" Likely there is still confusion about exactly how it should work and be fixed.
On 2010-03-30, at 8:56 PM, Andreas Raab wrote:
On 3/30/2010 8:19 PM, John M McIntosh wrote:
Mac Carbon VM 4.2.3b1 sound recording busted
Must always remember to test (lot more) things after applying VMMaker changes. I'll have a 4.2.4b1 VM in a few days after some dust settles.
But for now if you hit the SoundRecorder record button in your squeak.image it will crash.
Oh dear. Same for Windows 4.0.1. Any ideas what's causing this?
Cheers,
- Andreas
vm-dev@lists.squeakfoundation.org
-
Andreas Raab -
David T. Lewis -
John M McIntosh