Re: Lost items from Port 2 (flash) in 49G+ (again)

Hi Joe,

thanks for the report.

Methinks it should not work different,
either with or without a prior TOTEMPOB.
In any case, you always have a pointer
to an object if 'recalled' to the stack,
and it must not make a difference if the pointer
points to TEMPOB or to USEROB.

I think there's problem with the copy routine,
maybe a wrong counter, an overlapping address,
or even an overflow.
The latter two options come in mind especially
if you take into consideration that the bug
only seems to happen with an object near the
memory boundary.



Regards

Raymond


"Joe Horn" <joehorn@xxxxxxxxxxx> schrieb im Newsbeitrag
news:1134471998.236986.100710@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>I think I've isolated the Port 2 Loss Bug!
>
> Any time that the contents of the very first variable in the HOME
> directory ( HOME VARS HEAD ) is stored into Port 2 without first
> NEWOB'ing it, Port 2 acts as if it is corrupted, and the problem can be
> completely fixed by deleting that variable from Port 2.
>
> Example:
>
> (1) Store any object > 2.5 bytes into any new name in the HOME
> directory.
> (2) Recall that object to the stack.
> (3) Store that object (unmodified, unedited, un-NEWOB'ed) into Port 2.
> (4) Warmstart (ON+C) --> Invalid Card Data
> (5) Purge that object from Port 2.
> (6) Warmstart --> no error.
> (7) Recall the object to the stack again.
> (8) Execute NEWOB on it.
> (9) Store it as-is into Port 2.
> (10) Warmstart --> no error.
>
> The contents of the first variable in HOME seems to always end at
> memory address #FFFF6. Storing THAT into Port 2 is what seems to cause
> the trouble. I'm pretty sure that this covers the cases that John has
> posted so far.
>
> The name that's used doesn't seem to matter. << HOME VARS HEAD RCL
> :2:AnyName STO >> always seems to screw up Port 2, no matter what is
> used in place of AnyName. Thereafter, :2:AnyName PURGE always seems to
> fix it. PINIT fixes it too, but it wipes out far more than necessary
> and should be avoided.
>
> -jkh-
>


.

Relevant Pages

  • [GIT PATCH] SCSI fixes for 2.6.30-rc4
    ... flush the rport Q after logging off dns port ... lpfc 8.3.1: Update version to 8.3.1 ... @shost: Scsi_Host pointer. ... @phba: lpfc_hba pointer. ...
    (Linux-Kernel)
  • Re: Port 139 offen. Hilfetexte bisher ohne Erfolg
    ... Es lauscht ein Dienst auf dem lokalen Port 139 und nimmt auf der ... zwischen dem TCP/IP Stack des ... Wenn eine TCP Verbindung initiiert wird, ... TCP/IP Stack des OS statt. ...
    (de.comp.security.misc)
  • Re: BT Stack under WM2005
    ... Under WM5.0 (with the Microsoft stack) once you have paired a device you can view it's properties in Settings> Connections> Bluetooth and view the properties, if you check Serial Port and save you can then go to the COM Ports tab of the Bluetooth settings applet and map an outgoing COM port to your device. ... Although there's always one preliminary step I have to take prior to engaging this kind of communication: I've either got to use the built-in GPS manager, which is unfortunately hidden under WM5 by default in order to map COM ports to the incoming data from Picoplug. ... Every time I restart a programme which is attempting to communicate with the Picoplug, connection gets established but only to break down a few seconds later. ...
    (microsoft.public.pocketpc.developer)
  • Re: bluetooth application development
    ... bluetooth stack give the ... possibility to make a BT discovery, pairing and VirtualCOM port attach. ... Once you have made this association (in PocketPC outbound VCOM usually ...
    (microsoft.public.dotnet.framework.compactframework)
  • Re: Windows Mobile 6.1 trouble
    ... There should not be any differences in the way you assign a virtual COM port using the Microsoft Bluetooth stack on WM6.1. ...
    (microsoft.public.dotnet.framework.compactframework)