View Issue Details

IDProjectCategoryView StatusLast Update
0008878Multi Theft Auto : San AndreasClientpublic2015-06-27 03:52
ReporterZver-CR Assigned Tosbx320  
Status resolvedResolutionfixed 
Product Version1.5 
Target Version1.5Fixed in Version1.5 
Summary0008878: [1.5] Client-side getElementID returns garbage

After I updated client to version 1.5, getElementID() returns strange characters, like "ċ쐣਩j"

Steps To Reproduce

/start test_id
and see the result in the chat

TagsNo tags attached.



2015-06-10 18:48

viewer   ~~0023365

this bug also occurs in map editor


2015-06-25 22:19

manager   ~~0023427

Last edited: 2015-06-26 16:01

Confirmed in v1.5-release-7307
Server returns correct info, client returns garbage.

Quicker way to test:

local mkr = createMarker(0, 0, 0, "cylinder")
setElementID(mkr, "abc")
outputChatBox("ID: "..getElementID(mkr))

Returns this:

Edit: It seems that if you aim at something in map editor, the value being returned each frame is different, something got seriously messed up and it's breaking stuff like you can't select things from the element list.


2015-06-27 03:51

administrator   ~~0023446

Nasty bug. We relied on undefined behaviour there which worked in VS2008, but does no longer work under VS2013.

const char* szName = pEntity->GetName ();

This calls CClientEntity::GetName, which returns a copy of the SString CClientEntity::m_strName. Afterwards SString::operator const char* is invoked, returning a pointer to a char array containing our id.+

However since our return value of CClientEntity::GetName is not stored anywhere it now gets deleted and the SString's memory area is free for reuse per the standard. This also invalidates our char pointer to the name which was incorrectly reused.

Fixed in

Also changed CClientEntity::GetName to have a return type of const SString& and be const itself to avoid more issues of this kind with CClientEntity::GetName.

Issue History

Date Modified Username Field Change