Good catch Mark, I notice the getbuffer line and then the read to eof -- Claudi can answer if that was a loop but from looking at his code, in the stack he shared with me, the read from driver until eof is where this crashed:
> if the hilitedButtonName of grp "driverFile radioGrp" = "driver" then > read from driver tDriver until EOF -- end EOF > else > read from file tDriver until empty --EOF -- empty as in dictionary > end if He didn't do a 'repeat loop' but rather the read from driver is reading until it finds an EOF which must be looping with no EOF. Right? This is/was the way to read the port in previous FTDI instances and in Sarah's serialTest stack as well. It's possible/ is it possible that we can't read this way with the Atmega8u2 due to OSX 10.6.6 and how it handles the serial/usb buffer. Or is it more like the EOF is wrong. I still have not found a definitive answer on the Arduino Uno forums as to what the line endings are when the Uno fills the buffer or how big the buffer is on the board. I understand that the Mac side is rather larger than the Uno side. I am trying to write a software flow control sketch and LC combo now to see if it will work (with out resetting the Uno each time). The question remains that this piece of code works in previous OS versions so what has changed in 10.6.6 and what needs changed in LC to read until EOF with out crashing. Or is that what you meant by That is Not a Good Thing? ;-) Thanks for catching that. -- Tom McGrath III http://lazyriver.on-rev.com 3mcgr...@comcast.net On Jan 26, 2011, at 8:08 PM, Mark Wieder wrote: > Claudi- > > Wednesday, January 26, 2011, 2:48:22 AM, you wrote: > >> Thread 0 Crashed: >> 0 libSystem.B.dylib 0x91ddde42 __kill + 10 >> 1 libSystem.B.dylib 0x91e5023a raise + 26 >> 2 libSystem.B.dylib 0x91e5c622 __abort + 97 >> 3 libSystem.B.dylib 0x91e5c68a _cproc_fork_child + 0 >> 4 libstdc++.6.dylib 0x92049005 0x92001000 + 294917 >> 5 libstdc++.6.dylib 0x9204710c __gxx_personality_v0 + >> 1108 >> 6 libstdc++.6.dylib 0x9204714b std::terminate() + 29 >> 7 libstdc++.6.dylib 0x92047261 __cxa_throw + 101 >> 8 libstdc++.6.dylib 0x920475d8 operator new(unsigned >> long) + 100 >> 9 libstdc++.6.dylib 0x92047689 operator new[](unsigned >> long) + 17 >> 10 com.runrev.livecode 0x000a3048 >> MCExecPoint::getbuffer(unsigned int) + 56 >> 11 com.runrev.livecode 0x00141134 >> IO_read_to_eof(IO_header*, MCExecPoint&) + 52 >> 12 com.runrev.livecode 0x0006d3bb >> MCRead::exec(MCExecPoint&) + 2555 >> 13 com.runrev.livecode 0x00103a64 >> MCHandler::doscript(MCExecPoint&, unsigned short, unsigned short) + > > Well, from a quick look at things, I'd say you started a script that > did a "repeat until EOF" and LC crashed trying to allocate memory > space for the read. That is Not a Good Thing. > > -- > -Mark Wieder > mwie...@ahsoftware.net > > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
