Smalltalk › Squeak › Squeak VM

serial plugin crash on unix

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

Markus Lampert

serial plugin crash on unix

Hi,

the serial plugin for unix (4.4.7.2357) can take the vm down. The following code

demonstrates the issue:

s := SerialPort new.
40 timesRepeat: [
s openPort: '/dev/ttyS0'.
s close]

I have attached a version of sqUnixSerial.c which fixes the problem. It allows
for 32 _different_ serial ports to be opened and closed (as often as necessary).

It also prevents the segmentation fault. If more than 32 different serial ports
are attempted to be opened the request fails.

The changes are in line 202, and 220 - 352.

In the current implementation (trunk) it is not possible to find out if
#openPort: was successful or not and I don't know how to fix that.

Have fun,
Markus

sqUnixSerial.c (17K) Download Attachment

David T. Lewis

Re: serial plugin crash on unix

On Sat, Mar 05, 2011 at 04:00:03PM -0800, Markus Lampert wrote:

>
> Hi,
>
> the serial plugin for unix (4.4.7.2357) can take the vm down. The following code
>
> demonstrates the issue:
>
> s := SerialPort new.
> 40 timesRepeat: [
> s openPort: '/dev/ttyS0'.
> s close]
>
> I have attached a version of sqUnixSerial.c which fixes the problem. It allows
> for 32 _different_ serial ports to be opened and closed (as often as necessary).
>
> It also prevents the segmentation fault. If more than 32 different serial ports
> are attempted to be opened the request fails.
>
> The changes are in line 202, and 220 - 352.

Thanks Markus,

This is on Mantis at http://bugs.squeak.org/view.php?id=7610, and I will
forward your fix to Ian also. It looks very good to me although I did not
test it.

>
> In the current implementation (trunk) it is not possible to find out if
> #openPort: was successful or not and I don't know how to fix that.

I am not a user of the serial port plugin, but it sounds like this would
be easy to fix. It looks like the support code returns 0 on success and
-1 on failure, so we could pass that back as the result of the primitive,
or return true/false as the result of the primitive call. Would something
like that help?

Dave

Markus Lampert

Re: serial plugin crash on unix

In reply to this post by Markus Lampert

Hi Dave,

Thanks for entering the Mantis bug and forwarding the issue. Didn't know the
process for vm issues. Next time ....

I start to understand how the plugins work. The return value of open and close
is actually ignored by the interface code, so the only thing that matter is
success(true/false).

If I understand the mailing lists correctly I should move the discussion about
changing the return value to squeak-dev.

Have fun,
Markus

----- Original Message ----

> From: David T. Lewis <[hidden email]>
> To: Squeak Virtual Machine Development Discussion
><[hidden email]>
> Sent: Sun, March 6, 2011 3:46:51 PM
> Subject: Re: [Vm-dev] serial plugin crash on unix
>
>
> On Sat, Mar 05, 2011 at 04:00:03PM -0800, Markus Lampert wrote:
> >
> > Hi,
> >
> > the serial plugin for unix (4.4.7.2357) can take the vm down. The following
>code
>
> >
> > demonstrates the issue:
> >
> > s := SerialPort new.
> > 40 timesRepeat: [
> > s openPort: '/dev/ttyS0'.
> > s close]
> >
> > I have attached a version of sqUnixSerial.c which fixes the problem. It
>allows
>
> > for 32 _different_ serial ports to be opened and closed (as often as
>necessary).
>
> >
> > It also prevents the segmentation fault. If more than 32 different serial
>ports
>
> > are attempted to be opened the request fails.
> >
> > The changes are in line 202, and 220 - 352.
>
> Thanks Markus,
>
> This is on Mantis at http://bugs.squeak.org/view.php?id=7610, and I will
> forward your fix to Ian also. It looks very good to me although I did not
> test it.
>
> >
> > In the current implementation (trunk) it is not possible to find out if
> > #openPort: was successful or not and I don't know how to fix that.
>
> I am not a user of the serial port plugin, but it sounds like this would
> be easy to fix. It looks like the support code returns 0 on success and
> -1 on failure, so we could pass that back as the result of the primitive,
> or return true/false as the result of the primitive call. Would something
> like that help?
>
> Dave
>
>