Hiking in Heimbach (Eifel)

As there were two holidays last week, I decided to get out of town to take a short vacation in Heimbach (Eifel) for some hiking. The Eifel is only two hours away by train, but you feel so much closer to nature around all the forests and lakes.

Burg Hengebach

Burg Hengebach mit Brücke

The landscape is dominated by various reservoirs and dams, most notably the Rur dam. Below the view from the Hirschley atop the Kermeter onto the Rur lake.

Hirschley Panorama

Rursee

More reservoirs downstream from the Rur dam.

Stauanlage Heimbach

Rurtalsperre

The Art Nouveau hydro-electric power plant in Heimbach.

Jugendstilkraftwerk

Advertisements

Vitra Architecture Tour

On the last day of my Obereggenen vacation, we went to Vitra in Weil am Rhein. They are a maker of designer furniture, show-casing some of their offerings in this stylish building.

Vitra Alice in Wonderland

Vitra Haus

As part of their architecture tour we got to see their production facilities where almost every building has been designed by famous architects; e.g. passage cover by Álvaro Siza and fire station by Zaha Hadid.

Vitra Überdachung

Vitra Fire Station

Vitra Zelt

Vitra Zeltdach

Vitra Bank

The Case of a Delphi Application hanging in ExitProcess

A colleague came to me with a Delphi application that would not shut down, but just hang. The application in question had been refactored such that one module was extracted into a DLL to be reused in another application. When this extracted module was loaded into the application and the application was closed, it would hang. If the module was not loaded, the application would shut down normally.

Analysis

Debugging the application was initially unsuccessful. Stepping through our code we verified that the shutdown logic executed normally with destructors running as expected. Interestingly, it was not possible to break into the application once it had become unresponsive. Trying to pause the hung program from within the IDE would simply cause the IDE to hang as well.

Thus we used Process Explorer instead to look at the application’s threads and their callstacks.

There we saw that there was one thread stuck on a call to WaitForSingleObject which originated in our DLL code. Higher up the callstack was ExitProcess. I looked at the documentation for ExitProcess to see look for ways in which it could deadlock. One sentence looked promising: “If one of the terminated threads in the process holds a lock and the DLL detach code in one of the loaded DLLs attempts to acquire the same lock, then calling ExitProcess results in a deadlock.” But since there was only one thread, this could not be it.

Looking next at what happens exactly inside ExitProcess, two other things jumped at me:

  • All threads are terminated (except for the one calling ExitProcess).
  • All DLLs are unloaded.

Cause

It turns out, the initial analysis that “the shutdown logic executed normally” was wrong. One of the shared units compiled into the DLL (through several layers of indirections), had a finalization section. In this finalization section, a background thread that had been created in the corresponding initialization section, was being destroyed. As part of the destructor code, the thread class was waiting for an event that was set when the thread had stopped executing.

Holzscheite (4)

This finalization section was running as part of the “all DLLs are unloaded” step by ExitProcess. Unfortunately, all threads (including the one created in the initialization) had already been terminated. I am not quite sure how that was accomplished, but it apparently circumvented the normal thread termination logic which set the event that the thread had stopped executing.

This is different for code in the main application, where finalization sections are run while the application is still in working order.

Solution

Instead of waiting for the thread to set its “stopped executing” event, I wait on the thread handle to check if the thread was even there to set the event. When run from the DLL’s finalization section, this detects the thread’s absence and just returns.

Tour of Meyer Werft, Papenburg

Last Saturday I attended the CIM Lingen conference (again). Since I already was in the region, I figured why not add one more day to the trip and visit the Meyer Werft shipyards in nearby Papenburg as well.

World of Dream Detail

The World Dream docked outside the huge Dockhalle 2 factory building as the ship is being prepped for its maiden voyage later this year.

World of Dream Totale

Most of the tour at Meyer Werft was spent in the visitors center, watching video of their 220+ year history and looking at model of some of the 700+ ships they built in this time.

One of the ships with the most interesting history is the Graf Goetzen. Built in 1913 at the shipyard in Papenburg for the German Empire, it was immediately disassembled after it was finished and its parts shipped in boxes to Africa. After brief use as a naval vessel and being sunk, it was raised years later, renovated and continues to be operated on Lake Tanganyika to this day.

Graf Goetzen

But the highlight came at the end of the two-hour tour: a peek into the two factory buildings Dockhalle 1 and Dockhalle 2.

Meyer Werft Kleine Halle

Pictured above is the smaller Dockhalle 1 where they built parts for final assembly in Dockhalle 2. The latter is so large, that it is impossible to fully take it in through the small window in the visitors area.

Interesting detail: one of the cranes in Dockhalle 1 was actually made in East Germany (“Deutsche Demokratische Republik”). Apparently, the East German buyers of one of the ships built by Meyer did not have enough hard currency to pay for it and delivered equipment to make up the difference.

Kran aus der DDR

The company logo, then and now.

Meyer Werft Logo Alt

Meyer Werft Logo Neu