[Vm-dev] serial plugin crash on unix

Markus Lampert markuslampert at yahoo.com
Mon Mar 7 02:57:01 UTC 2011


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 <lewis at mail.msen.com>
> To: Squeak Virtual Machine Development Discussion 
><vm-dev at lists.squeakfoundation.org>
> 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
> 
> 




More information about the Vm-dev mailing list