Wind River Blog Network

RDC in China

By Tomas Evensen

I just came back from a couple of weeks in China. Fascinating country. Besides the usual customer visits, we also held three Regional Development Conferences (RDCs) in Shenzhen, Shanghai and Beijing.

The RDCs were a huge success with on average more than 400 attendees per day. And they were all very interested in hearing about Wind River's latest offerings and future plans.

How do I know they all were interested? Well, my leading indicator was that all seats were taken from the front working towards the back. Somewhat different from your typical American or European conference, where the back seats seem to be the hottest commodity. (BTW, I am of course not indicating that our American and European friends are not interested... Perhaps they have better eye sight).

Continue Reading ››

Mitigating Risk

By Mike Deliman

The phone rings.  A customer has an application destined for a high-risk environment, and somewhere in test they've found a new unanticipated condition.  A "Tiger Team" is formed - a group of experts who've "been here before", who understand the priority and the risks, and know how serious it is. Many times a Tiger Team may give the go / no-go, the final answer that either saves a mission, or drops all that work into the dust-bin.  Such a team itself represents a *lot* of work, frustration, and time - investigations may run on days, weeks, or months, as long as they reach their conclusion on-time.  And there's the one facet that can't be changed by any engineering practice:  Time.

Continue Reading ››

Reporting Exceptions in QA

By Bulent Kasman

I now have a habit of asking for the Exception Detection and Reporting (ED&R) log as a minimum, and the core file if available, whenever QA observes exceptions during testing. If you are not a VxWorks 6.x user, ED&R log is like a signature of a core dump. It briefly describes the exception by providing the address of the crash, stack backtrace, register values, and even a disassembly of the surrounding code. Core file lets one use Wind River Workbench debugger and other host tools, like the host shell if you like to use command line to dump memory and see tasks at the time of exception. In many cases this all I need to pinpoint the root cause, and fix the defect.

Alternative used to be rather painful, time consuming, and much less deterministic. It preempts what I was doing, so that I can setup my environment to recreate the same crash scenario based on the description of the eye-witness (i.e. the tester). If the bug is obvious enough this method works, of course. But, what if I can't reproduce the crash? Was it a faulty setup in the QA lab or was it some rare race condition that caused the exception? And, if I do reproduce the crash, the first thing I'll probably do is to look at it using a debugger, which is what the core file gives me to start with.

Continue Reading ››