Lotus Notes / Domino 10 > ND10: Entwicklung

Zugriffe auf DB auslesen mit CLASSUserActivity

<< < (3/5) > >>

eknori (retired):
OK, habe jetzt dem Support bestätigt, daß der Code auf Windows 2008 R2 FP1 und Domino 10.0.1 nicht crasht.
Mitlerweile sitzen aber auch Leute aus der Entwicklung an der Sache.

eknori (retired):
So, nachdem wir jetzt einen kompletten Tag verloren haben, weil der Support in einer nicht unterstützten Umgebung den Fehler nicht reproduzieren konnte, jetzt endlich die Meldung:


--- Zitat ---Hi Ulrich,
 
Issue is reproducible with Win2016 10.0.1 & Win2016 10.0.1 FP1 & FP2.
 
I will further collaborate this issue with our product development team and update you the
findings as soon as possible.
 
Regards
--- Ende Zitat ---

Lessons learned so far:

1. Support immer nach der dort eingesetzten Version von OS und Domino fragen.

eknori (retired):
Die Ursache für den Crash ist eigentlich klar. negativer pointer



Das mag dann das CopyMemory nicht.

Die Frage ist nur, warum kommt da ein neg. pointer?

SD:
Das hier scheint das falsche zu machen:


--- Code: ---puActivity = W32_OSLockObject(Me.rethUserInfo)
--- Ende Code ---

Auf dem Server geht da 85 rein und es kommt eine solche negative Zahl raus. Das Script läuft auch auf eine Replik der Zieldatenbank, da geht 87 rein und es kommt eine negative Zahl raus.


--- Code: ---Me.rethUserInfo: 85
puActivity: -532537288

Me.rethUserInfo: 87
puActivity: -1553004888
--- Ende Code ---

Lasse ich das selbe Script auf meinem Client laufen, dann geht rethUserInfo 4114 rein und es kommt eine positive Zahl raus.

Ich vermute mal die Zahl ist eine Speicheradresse, die angibt, wo im Speicher aktuell die ActivityLogs anfangen. Dann wird die Größe, die der Logeintrag hat (ohne Username) nach vorne gesprungen und der Teil wegkopiert, der so lang ist, wie der Usereintrag sein müsste. Jetzt weiß ich nur leider nicht, ob Me.rethUserInfo schon falsch ist, oder W32_OSLockObject den falschen Wert daraus macht.

Der Wert für Me.rethUserInfo kommt wohl hier her:


--- Code: ---StatusResult = W32_NSFDbGetUserActivityExtended(Me.hDb, &h0, Me.pDbActivityExtended, Me.rethUserInfo, Me.retUserCount)
--- Ende Code ---

Me.retUserCount scheint richtig zu sein. Dafür bekomme ich auch auf dem Client und auf dem Server den gleichen Wert. Ich habe mal spaßeshalber Me.rethUserInfo mit einem leicht höheren Wert überschrieben und damit sofort den Server gecrasht mit "PANIC: LookupHandle: handle out of range". Ich schätze mal der Me.rethUserInfo-Wert, der da raus kommt stimmt wohl und W32_OSLockObject macht was seltsames draus.

Der Umstand, dass die Zahl negativ ist und dass sie so groß (sprich klein) ist, klingt für mich nach einem Problem der Long-Variable. Long geht von -2.147.483.648 bis 2.147.483.647. Kann es sein, dass puActivity hier einmal die Runde gemacht hat und hinten im Minus wieder rausgekommen ist?! Ich hab mal versucht W32_OSLockObject auf "As Double" zu ändern und die anderen Long-Variablen auch, aber das war wohl zu stumpf. Da kommt jetzt auf dem Server nur noch 0 dabei raus (auf dem Client "-1,#IND" ... weird).

Also mein best guess wäre, dass W32_OSLockObject intern mit Long-Variablen arbeitet, die zu klein sind für die Speicherwerte auf dem Windows2016-Server.

SD:
Oh, jetzt hab ich die Variablen zurück auf Long geändert und bei einem neuen Durchlauf ist puActivity jetzt 851806112 (was wohlgemerkt weniger ist als das Long-Maximum von 2.147.483.647). Ich habe dann den Rest des Codes wieder mitlaufen lassen und siehe da, funktioniert.

Ich schätze mal da sind die ActivityLogs zufällig in einem Speicherbereich mit kleiner Adresse gelandet, wodurch die Longs jetzt nicht mehr überfordert werden.

Hat zufällig jemand eine W32_OSLockObject mit longeren Longs? ^^

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete