Ralf Hüsing

“Die Transaktion (Prozess-ID xxxx) befand sich auf Sperre Ressourcen aufgrund eines anderen Prozesses in einer Deadlocksituation und wurde als
Deadlockopfer ausgewählt. Führen Sie die Transaktion erneut aus.”

Soweit ich das verstanden habe treten Deadlock’s auf wenn zwei Transaktionen dauerhaft auf eine bestimmte Ressource warten würden. Eine Ressource kann zbspl. eine Speicher-Seite sein. Der MS-SQL-Server erkennt das und wählt dann einen Prozess aus der gekillt wird.

Das ganze ist im MSDN recht umfangreich beschrieben: Deadlocks.

So könnte man Zahlen mal auf eine andere Art sortieren:

SELECT 3 AS ID
UNION ALL
SELECT 1 AS ID
UNION ALL
SELECT 2 AS ID
ORDER BY ID

Sieht dann in etwa so aus:

Möchte man Eingaben flexibel und evtl. komplexen Prüfungen unterziehen kann man sich die Fähigkeiten von SQL zu nutze machen.
Ich gehe hier davon aus das die Anwendung generell eine Datenbankverbindung hat und nicht extra wegen der Prüfung eine Verbindung aufbauen muss.

Ein Beispiel:
Der Benutzer gibt eine Zeichenfolge ein: “D016381″.

Die Anwendung muss nun etwas bestimmtes tun wenn:
Die Eingabe mit D beginnt, gefolgt von einer 0 und .. (was auch immer).

In jedem Falle ist die Prüfung nicht trivial. Hier bieten sich reguläre Ausdrücke an, jedoch ist nicht in allen Programmiersprachen “mal eben so” möglich RegEx zu verwenden.

Diese Prüfung kann sehr einfach mittels SQL umgesetzt werden.
Es bietet sich der LIKE oder REGEXP Vergleichsoperator an:

SELECT -1 AS OK WHERE 'D016381' LIKE 'D0%'

Diese Abfrage liefert einen Datensatz (mit einer Spalte “OK” mit dem Wert -1) wenn der Benutzer D gefolgt von einer 0 gefolgt von “irgendwas” eingegeben hat.

Es ist nun natürlich ohne weiteres möglich die komplexität der Abfrage zu erhöhen:

SELECT -1 AS OK WHERE ('D016381' LIKE 'D0%' AND 'D016381' NOT LIKE '%2') OR ('D016381' LIKE 'K%')

Heißt, wenn die Eingabe:

(D gefolgt von einer 0 gefolgt von “irgendwas” UND die Eingabe nicht auf 2 endet) ODER die Eingabe mit einem “K” beginnt dann… soll die Anwendung etwas tun.

In der Endkonsequenz kann man diese Filter (bzw. SQL-Statements) in einer SQL-Tabelle speichern und zur Laufzeit das jeweilige SQL-Statement generieren und ausführen.
Somit ist man extrem flexibel da man die Abfragen / Prüfungen jederzeit (für alle Anwendungen die diese SQL-Tabelle verwenden) anpassen kann.

Wer findet den Bug in folgendem Code?

    For Each oControl In Controls
      Select Case LCase(oControl.Tag)
      Case "ziel", "quelle", "bedingung", "Feldliste"
        ' Mach irgendwas mit oControl wenn dessen Tag passt
      End Select
    Next oControl

Mit folgendem TSQL-Script wird der Inhalt aller in der aktuellen Datenbank vorhandenen Benutzer-Tabellen gelöscht:

Sollte TRUNCATE TABLE wg. Referenzen oä. nicht funktionieren kann es durch das etwas langsamere DELETE FROM ersetzt werden.

Bevor man das Script ausführt sollte man mehrfach Prüfen das man in der richtigen Datenbank / auf dem richtigen SQL Server ist.

DECLARE @table varchar(128)

DECLARE CUR CURSOR FOR
SELECT sysobjects.name FROM sysobjects WHERE type = 'U'

OPEN CUR

FETCH NEXT FROM CUR INTO @table

WHILE @@FETCH_STATUS = 0
BEGIN
	EXECUTE ('TRUNCATE TABLE [' + @table + ']')
	FETCH NEXT FROM CUR INTO @table
END

CLOSE CUR
DEALLOCATE CUR

' /**
' Konvertiert Dezimal Zahlen in Hex
' **/
Public Property Get pDec2Hex(lDec As Long, Optional ByVal lLength As Long = 4, Optional sPrefix As String = "0x") As String
  Dim sHex    As String
  Dim lHexLen As Long

  sHex = Hex(lDec)

  lHexLen = Len(sHex)

  If lLength < 0 Then lLength = 0

  If lHexLen < lLength Then
    sHex = String(lLength - lHexLen, "0") & sHex
  End If

  sHex = sPrefix & sHex

  pDec2Hex = sHex
End Property

' /**
' Hexadezimal nach Dezimal
' @bug: Es werden alle Zeichen in sHex verarbeitet bis zum zeichen ende oder zum ersten ungültigen Zeichen.
'       Beispiel: "0xFFz" ergibt 255
' **/
Public Property Get pHex2Dec(ByVal sHex As String, Optional sPrefix As String = "0x") As Long
  Dim lPrefix As Long

  lPrefix = Len(sPrefix)

  If Left(sHex, lPrefix) = sPrefix Then
    sHex = Mid(sHex, lPrefix + 1)
  End If

  On Local Error Resume Next

  pHex2Dec = CLng(Val("&H" & sHex))
End Property

Eine sehr übersichtliche SQL Sicht:

Folgendes Perl-Script konvertiert alle Hexadezimalen Zahlen (0x…) der Standardeingabe (stdin) in Dezimale Zahlen und gibt es auf der Standardausgabe (stdout) aus:

#!/usr/bin/perl -lw

use strict;

while (<>) {
        chomp;
        s/0[xX]([a-fA-F0-9]+)/sprintf('%d', hex('0x'.$1))/eg;
        print $_;
}

Benutzung in etwa wie folgt:

perl hex_2_dec.pl < hex.txt > dec.txt

“hex.txt” enthält beispielsweise folgende Zeile:

#define CSIDL_DESKTOP                   0x0000        // 

“dec.txt” enthält folgende Zeile:

#define CSIDL_DESKTOP                   0        // 

Um in einer VB6-Routine (Function, Sub oder Property) mehrere Fehler ordentlich abzufangen muss eine etwas merkwürdige Kombination von “on local error” und “resume” verwendet werden.

Diese Beispiel-Sub geht von einem simplen “Form1″-Formular sowie einem “Command1″-Button aus.

Das Beispiel versucht mehrere Eigenschaften des aktuellen Objektes (”Form1″) abzufragen wobei die Sub verlassen werden soll wenn kein Fehler auftrat.
Die Eigenschaften sind “Error1″ gefolgt von “Error2″ und letztlich “Caption” was die Titel Zeile des Formulars ist.

Geht man diese Sub im Debug Modus Schritt für Schritt durch (F8 drücken) sieht man sehr schön wie “wild” hin und hergesprungen wird. Das ganze ist nicht ganz fein, funktioniert aber.

Private Sub Command1_Click()
  Debug.Assert ("F8 drücken um die Aufrufe einzeln durchzugehen" = "")

  On Local Error GoTo try_2

  Debug.Print CallByName(Me, "Error1", VbGet)
  Exit Sub

try_2_real:
  On Local Error GoTo try_3
  Debug.Print CallByName(Me, "Error2", VbGet)
  Exit Sub

try_3_real:
  On Local Error GoTo real_error
  Debug.Print CallByName(Me, "Caption", VbGet)
  Exit Sub

try_2:
  Debug.Print "try_1: " & Err.Number & " " & Err.Description
  Resume try_2_real

try_3:
  Debug.Print "try_2: " & Err.Number & " " & Err.Description
  Resume try_3_real

real_error:
  Debug.Print "real_error: " & Err.Number & " " & Err.Description
  Exit Sub
End Sub

Zum Vergleich mal ein nicht funktionierendes Beispiel:

Private Sub Command2_Click()
  Debug.Assert ("F8 drücken um die Aufrufe einzeln durchzugehen" = "")

  On Local Error GoTo try_2
  Debug.Print CallByName(Me, "Error1", VbGet)
  Exit Sub

try_2:
  On Local Error GoTo 0
  On Local Error Resume Next
  On Local Error GoTo try_3
  Debug.Print CallByName(Me, "Error2", VbGet)
  Exit Sub

try_3:
  On Local Error GoTo real_error
  Debug.Print CallByName(Me, "Caption", VbGet)
  Exit Sub

real_error:
  Debug.Print "real_error: " & Err.Number & " " & Err.Description
  Exit Sub
End Sub

Warum das zweite Beispiel nicht funktioniert bzw. nur das Erste liegt vermutlich daran das man während einer “Fehlerbehandlung” keine andere Fehlerbehandlung aktivieren oder die aktuelle deaktivieren kann. Aufgrund des “Resume try_2_real” im ersten Beispiel wird die Fehlerbehandlung zurück gesetzt um umgehend wieder gesetzt zu werden. Ein Vorteil könnte sein das man gezielt auf Spezielle Fehler reagieren kann.

suidexec führt Programme als root aus ohne jegliche Überprüfung wie zBspl. sudo oder suexec.

Lizenz ist .. mir egal.

Installation geht via make install, die Binary liegt dann in /usr/bin/suidexec.
Eine Deinstallation geht via make uninstall - oder man löscht einfach /usr/bin/suidexec.

Alle suidexec übergebenen Parameter werden an das zu startende Programm weitergereicht, suidexec selbst hat somit keinerlei Parameter.