{"id":1128,"date":"2015-01-03T11:54:24","date_gmt":"2015-01-03T10:54:24","guid":{"rendered":"http:\/\/blog.m-ri.de\/?p=1128"},"modified":"2015-01-03T11:54:24","modified_gmt":"2015-01-03T10:54:24","slug":"wenn-man-nicht-genau-aufpasst-mit-overlapped-io-und-cancelio-vergisst","status":"publish","type":"post","link":"http:\/\/blog.m-ri.de\/index.php\/2015\/01\/03\/wenn-man-nicht-genau-aufpasst-mit-overlapped-io-und-cancelio-vergisst\/","title":{"rendered":"Wenn man nicht genau aufpasst mit Overlapped I\/O und CancelIo vergisst"},"content":{"rendered":"

Overlapped I\/O<\/em><\/a> ist eine Standardtechnik, die ja jeder kennt, der mit Datenquellen arbeitet, die „irgendwann“ mal Informationen liefert, man aber in der Zeit evtl. noch anderes zu tun hat \ud83d\ude09<\/p>\n

In meinem Fall, den ich hier schildere, benutzte unser Programm einen Service, mit dem es \u00fcber Named Pipes<\/em> kommuniziert. Das entsprechende Modul, ist schon ziemlich alt und hat seit ca. 3 Jahren keine \u00c4nderung erfahren. Aber jetzt auf einmal h\u00e4uften sich Meldungen, dass unser Programm beim Beenden einen UAE ausl\u00f6st.<\/p>\n

Entsprechende Minidumps wurden angefordert und deren Analyse zeigte eigentlich nicht viel wirklich erhellendes.\u00a0 Es sah alles danach aus, als ob ein Speicherblock freigegeben wird, der bereits freigegeben wurde.
\nLeider konnte das Szenario in unserem Testfeld nicht einfach nachgestellt werden. Und auch mehrfache Analyse des Sourcecodes brachte erst einmal nichts. Man ist manchmal einfach betriebsblind \ud83d\ude41<\/p>\n

Auff\u00e4llig war aber, dass diese Meldungen erst vereinzelt auftraten nachdem unsere Software auf VS-2013 Update 3<\/em> umgestellt war und diese an Kunden ausgerollt wurde. Und weiterhin konnten wir feststellen, dass alle diejenigen, die diesen Fehler gemeldet haben, relativ leistungsf\u00e4hige Rechner hatten.<\/p>\n

Schlie\u00dflich gelang es mir, das Szenario auf einem meiner Entwicklungsrechner nachzustellen.<\/p>\n

Das passierte:<\/p>\n

    \n
  1. Das Programm erhielt den Befehl zum Beenden.<\/li>\n
  2. Irgendwann wurde auch dem Thread, der mit dem Service interagiert gesagt, dass er sich beim Dienst ausloggen soll.<\/li>\n
  3. Der Dienst gibt auch brav den Befehl „Logoff“ an den Service.<\/li>\n
  4. Der Thread der in einer Schleife immer auf einen Response des Dienstes wartet beendet sofort.<\/li>\n
  5. Und nun erfolgte der Crash.<\/li>\n<\/ol>\n

    Die Ursache war ein fehlender CancelIo<\/em><\/a>. Damit das Beenden m\u00f6glichst schnell vonstatten geht, wurde darauf verzichtet, auf eine Antwort des Services zu warten, ob der Logoff<\/em> Befehl verstanden wurde, denn kurz danach wird sowieso die Pipe geschlossen. Keine gute Idee in diesem Fall! Das hatte auch den Grund darin, dass<\/p>\n

    Was ist also passiert \u2753<\/p>\n