Comments for Observations from Uppsala

Comment on Reverse History Part Three – Products by qwerty

qwerty — Thu, 12 Jan 2012 21:54:16 +0000

Do you know a good EU provider for electronic components?
-microprocessors
-led displays
-PCB boards
-diodes
-capacitors
-connectors
-etc…

Just to have something to actually debug on.
Thank you.

Comment on Reverse History Part One by Jakob

Jakob — Mon, 09 Jan 2012 19:30:00 +0000

@balor123
I think it can be very practical – the gdb implementation isn’t particularly fast or optimized, but that is just one implementation among many. Some are way faster.

What kind of checkpointing were you referring to?

Comment on Reverse History Part One by balor123

balor123 — Mon, 09 Jan 2012 15:49:48 +0000

Reverse debugging just isn’t practical. At least with GDB, it’s very slow, limited in functionality, and buggy. I use checkpointing all the time though.

Comment on Reverse History Part Three – Products by Observations from Uppsala » Reverse History Part One

Observations from Uppsala » Reverse History Part One — Sun, 08 Jan 2012 20:01:35 +0000

[...] so long that I had to break it up to make each post usefully short. Part two is about research, and part three about [...]

Comment on VMM Detection Myths and Realities from a Simics and Embedded Perspective by Observations from Uppsala » Reverse History Part Three – Products

Observations from Uppsala » Reverse History Part Three – Products — Sun, 08 Jan 2012 19:53:44 +0000

[...] an intrusion effect from running on a simulator rather than on a physical machine. This affects the timing of events, even with a software stack that is not modified. Still, the fact that you can run a complete real [...]

Comment on Reverse History Part Two – Research by Observations from Uppsala » Reverse History Part Three – Products

Observations from Uppsala » Reverse History Part Three – Products — Sun, 08 Jan 2012 19:52:46 +0000

[...] not just research prototypes. Part one of this series provided a background on the technology and part two discussed various research papers on the topic going back to the early 1970s. The first commercial [...]

Comment on Reverse History Part One by Observations from Uppsala » Reverse History Part Three – Products

Observations from Uppsala » Reverse History Part Three – Products — Sun, 08 Jan 2012 19:52:30 +0000

[...] reverse debugging available in a commercially packaged product and not just research prototypes. Part one of this series provided a background on the technology and part two discussed various research [...]

Comment on Reverse History Part Two – Research by Observations from Uppsala » Reverse History Part One

Observations from Uppsala » Reverse History Part One — Sun, 08 Jan 2012 19:51:31 +0000

[...] The text turned out to be so long that I had to break it up to make each post usefully short. Part two is about research, and part three about [...]

Comment on Keynote on System-Level Debug by qwerty

qwerty — Tue, 03 Jan 2012 12:06:20 +0000

Also sometimes is hardware which malfunctions due to environment factors ( temperature , moisture, oldage ).
I recently shopped around for an SSD drive. The MTBF published by the manufacturer is 2 million hours. That in years is 250.
250 continuous usage years! You need to keep it inside the functional envelope though otherwise it will eventually break suddenly and/or sooner.
In conclusion : once software is groomed and bug free it will run almost forever.

Comment on Keynote on System-Level Debug by qwerty

qwerty — Tue, 03 Jan 2012 07:03:12 +0000

Once a defect/bug is discovered you will have to fix/change the code, recompile and rerun.
You repeat these steps until no more misbehavior is perceived.
The more code you wrote the more less errors are in your first release.
One more thing : the correct behavior is mainly know to the software design team ; what can be perceived as a bug could have been an as-it-is feature.

Comment on SonyEricsson G900 – My New Phone, a Review (updated) by Observations from Uppsala » Touch the Screen vs Press a Button

Observations from Uppsala » Touch the Screen vs Press a Button — Mon, 26 Dec 2011 09:10:55 +0000

[...] Nano 3G, and a couple of iPod Touches. I used to have SonyEricsson Symbian-based P900, P990i, and G900 smart phones which also were combined touch/press devices with a [...]

Comment on Off-Topic: Video in the iPod Nano (Update, updated once) by Observations from Uppsala » Touch the Screen vs Press a Button

Observations from Uppsala » Touch the Screen vs Press a Button — Mon, 26 Dec 2011 09:02:54 +0000

[...] conflict between touching the screen and pressing the buttons. At the same time, I am using both an iPod Nano 3G, and a couple of iPod Touches. I used to have SonyEricsson Symbian-based P900, P990i, and G900 [...]

Comment on Dekker’s Algorithm Does not Work, as Expected by Jakob

Jakob — Sun, 27 Nov 2011 09:53:13 +0000

Getting a deadlock is kind of unexpected. Tying each thread to a core should make the error occur more often, as we are not at the mercy of OS scheduling then. But it is strange that it deadlocks, as nothing in this code should be able to spin forever. I would suggest attaching a gdb to the process and intercepting it to see what it is doing. Is it spinning in user land or is it off in the kernel somewhere?

Comment on Debug, Design, and Microsoft Data by qwerty

qwerty — Mon, 21 Nov 2011 13:19:23 +0000

“At least it seems to me that Windows is more stable today
than it was a couple of years ago.” – Well said
Windows 7 freezed on me only one time in like 2 1/2 years.
Linux desktop is a joke and Android crashes even in the simulator.
When i experienced a planned maintenance electrical power outage recently it felt weird.
The silence and darkness were refreshing. I started to long the preelectricity days : no constant humming or blinking, everything organic without a button in sight.

Comment on Dekker’s Algorithm Does not Work, as Expected by liu

liu — Sun, 20 Nov 2011 14:40:41 +0000

I got deadlock on my machine, even through I’ve bind the two threads on one cpu core using sched_setaffinity routing.

My machine:
Intel(R) Xeon(R) CPU E5520 @ 2.27GHz
8 cores

Comment on Virtual Platforms for Late Hardware and the Winds of History by Observations from Uppsala » DV* 30 Years

Observations from Uppsala » DV* 30 Years — Sun, 13 Nov 2011 20:32:57 +0000

[...] PNG), once again with no file extensions to hint at what is what. It underscores the importance of actual running programs and systems as a way to access our digital past. The data might all be there and readable, but with no software [...]

Comment on Dekker’s Algorithm Does not Work, as Expected by Jakob

Jakob — Sat, 29 Oct 2011 17:20:18 +0000

at http://gcc.gnu.org/onlinedocs/gcc/Atomic-Builtins.html , __sync_synchronize is described as a “full memory barrier”. I.e., all memory operations before the barrier will complete before moving on. With two barriers like this in place, the execution is essentially serialized and the code will be “correct”.

Comment on Dekker’s Algorithm Does not Work, as Expected by Sven Almgren

Sven Almgren — Wed, 26 Oct 2011 13:49:17 +0000

I wounder if using __sync_synchronize() would make this “correct”? Right before while().

turn = 2;
__sync_synchronize();
while((flag2 == 1) && (turn == 2)) ;

turn = 1;
__sync_synchronize();
while((flag1 == 1) && (turn == 1)) ;

or is it just luck that it works for me on an Intel Core i7? Have run it a few times with ./dekker 1000000000

Comment on Power Architecture Conference München 2008 by Observations from Uppsala » GPGPU for Instruction-Set Simulation – Maybe, Maybe not

Sat, 08 Oct 2011 19:18:06 +0000

[...] missed that Simics, unique among instruction-accurate mainstream simulators, is parallel since version [...]

Comment on The Adversarial Approach to Compilation by Jakob

Jakob — Sat, 08 Oct 2011 18:28:24 +0000

John Regehr : So anyway: tools are the answer and they lag far behind the compilers’ ability to exploit undefined behaviors.

Scary, but true. But the alternative, Ada-style restrictive behavior, is probably just as bad. A bit like memory consistency models - too rigid, and they are safe but slow. Too weak, and things are fast but impossible to use completely correctly. We need some better-defined middle ground it seems. Thanks for the information, interesting with the Spec behavior. As you say, not surprising.