Small Bug in the private message count

Discussion in 'Forum Related Discussions' started by Ranget, Dec 2, 2011.

Thread Status:
Not open for further replies.
  1. Ranget

    Ranget Registered Member

    Joined:
    Mar 24, 2011
    Posts:
    846
    Location:
    Not Really Sure :/
    Capture.PNG

    Lot of messages :D

    i think it's a small bug of some sort o_O
     
  2. LowWaterMark

    LowWaterMark Administrator

    Joined:
    Aug 10, 2002
    Posts:
    18,278
    Location:
    New England
    Not a bug... you're just very popular! :argh:
     
  3. Ranget

    Ranget Registered Member

    Joined:
    Mar 24, 2011
    Posts:
    846
    Location:
    Not Really Sure :/
    heheh :D


    Thanks

    Back to Normal :)
     
  4. MikeBCda

    MikeBCda Registered Member

    Joined:
    Jan 5, 2004
    Posts:
    1,627
    Location:
    southern Ont. Canada
    Wow, that's gotta be a new record, unread messages roughly 150x number of postings. :argh:
     
  5. Dude111

    Dude111 Registered Member

    Joined:
    Sep 30, 2008
    Posts:
    212
    Hey lowwaterMark,isnt 65535 the max the database can handle in 1 persons PM slot? (If allowed that many that is)
     
    Last edited: Dec 7, 2011
  6. LowWaterMark

    LowWaterMark Administrator

    Joined:
    Aug 10, 2002
    Posts:
    18,278
    Location:
    New England
    That's not actually where that value comes from when this error occurs. The variable that holds a member's "unread PM count" is of the SMALLINT type, and is also unsigned. So, it can only store values from 0 to 65535. The reason the value can get off is because of any locking or abort condition that prevents the value from being incremented when someone sends a member a new PM. Then when the member reads new PM, the value is decremented by one for each new PM read. If the value is 0 prior to reading another one, then it decrements from 0 to -1. Since the field is stored unsigned in the database, the -1 becomes 65535.

    vBulletin considers this variable to be non-critical, so, they ignore any errors when attempting to write the value. These occur infrequently, so, it's not a big deal. But, since they do occur, vBulletin has built-in correction routines to fix the value. I believe the value is recounted when you, the owner of the PM, either: 1. delete a PM. 2. mark any/all PM as read, or, 3. mark any/all PM as unread. Each of those functions recounts the PM total and unread PM count, fixing the values for the member record.

    So, if you ever see an odd value in the unread or total PM counts, just do one of those functions and they should be repaired.
     
  7. CloneRanger

    CloneRanger Registered Member

    Joined:
    Jan 4, 2006
    Posts:
    4,978
    @ LowWaterMark

    65535 is the same # of Ports we have !

    I know it's not port related :D but wondered if there was more too it that just a coincidence ? For eg: some programming etc type thing ?

    TIA
     
  8. LowWaterMark

    LowWaterMark Administrator

    Joined:
    Aug 10, 2002
    Posts:
    18,278
    Location:
    New England
    That maximum value is simply based upon the capacity of the standard 16-bit (2-byte) integer. It can represent 0 to 65535, if unsigned. Or, -32,768 to +32,767, if signed. This sized integer is a very commonly used variable in programming, especially for numerics that will have clearly limited values. The unlikelihood that someone would ever have more than 65535 unread PM lead vBulletin programmers to use this variable type for storing that value.
     
  9. CloneRanger

    CloneRanger Registered Member

    Joined:
    Jan 4, 2006
    Posts:
    4,978
    @ LowWaterMark

    So it is a programming thing. Thanks for the info :thumb:
     
  10. Dude111

    Dude111 Registered Member

    Joined:
    Sep 30, 2008
    Posts:
    212
    Yes thanx Mark for the explain :)
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.