AttachDynamicObjectToObject problem

[Dominik523]

I've been trying to find fix to this problem for few days now and I haven't found anything. Here's the problem. I have this function which should create three objects and attach two of them to the first object.

CreateBillboard(2, 2048.7175,1360.0249,10.6719,5.0234); // this is called under OnGgameModeInit
stock CreateBillboard(Type, Float:X, Float:Y, Float:Z, Float:rZ) // function located in an include file
{
    new id = -1;
    for(new i; i<MAX_BILLBOARDS; i++)
    {
        if(Board[i][Created] == false)
        {
            id = i;
            break;
        }
    }
// billboard
Board[id][Object][0] = CreateDynamicObject(1260, X, Y, Z, 0.0, 0.0, 0.0);

// black background 1
Board[id][Object][1] = CreateDynamicObject(7901, X + 0.3, Y - 0.1, Z + 5.6, 0.0, 0.0, 270.0);
SetDynamicObjectMaterialText(Board[id][Object][1], 0, "Your ad \ncan be here", 50, "Arial", 11, 1, 0xFFFF8200, 0xFF000000, 1);

AttachDynamicObjectToObject(Board[id][Object][1], Board[id][Object][0], 0.3, -0.1, 5.6, 0.0, 0.0, 270.0, true);

// black background 2
Board[id][Object][2] = CreateDynamicObject(7901, X + 0.7, Y - 0.1, Z + 5.6, 0.0, 0.0, 90.0);
SetDynamicObjectMaterialText(Board[id][Object][2], 0, "Your ad \ncan be here", 50, "Arial", 11, 1, 0xFFFF8200, 0xFF000000, 1);

AttachDynamicObjectToObject(Board[id][Object][2], Board[id][Object][0], 0.7, -0.1, 5.6, 0.0, 0.0, 90.0, true); // <---- this is the line which caused the crash

// after setting all the coordinates, I'm just rotating the object with the correct offsets of the last two objects
SetDynamicObjectRot(Board[id][Object][0], 0.0, 0.0, rZ);

When I compile the gamemode, everything is alright. No errors or warnings. That location is set around 20-30 meters from the spawn location and when I spawn and the objects begin to stream, my server crashes without any messages from crash detect or under OnPluginError. But when I set the location to, let's say, few kilometers from the spawning location, objects doesn't get streamed and server doesn't crash. I'm not sure if I gave you enough information about the problem so feel free to ask me for anything to post here and I'll do it. Cheers!

[Mellnik]

crashdetect, gdb please?

[Dominik523]

I'm just getting this from crash detect:

----------------------------------
[19:29:13]  Blank Gamemode by your name here
[19:29:13] ----------------------------------

[19:29:13] Number of vehicle models: 0
Console input: say test
[19:29:53] Incoming connection: 127.0.0.1:65026
[19:29:54] [join] Dominik523 has joined the server (0:127.0.0.1)
[19:29:55] [debug] Server crashed due to an unknown error

Going to install dgb debugger and then run the server. I'll post the results.

[Mellnik]

gdb samp03svr run

Then when it crashed just type "bt" and it should give us some useful info.

[ghost]

Maybe problem with YSF AttachObjectToObject, i''ll test it and if yes, will be fixed.

[Dominik523]

I'm running a server on the windows on local host just for testing. These are plugins that I use: plugins sscanf Whirlpool crashdetect streamer mysql I've downloaded gdb 7.9 for windows but I can't find the correct command to attach an executable file to it so I can start debugging. Give me some time so I can find it. EDIT: Here is the output.

Starting program: C:\Users\Dominik\Desktop\SAMP Realistic DM\samp-server.exe 
[New Thread 4184.0xb30]
warning: `C:\Windows\SYSTEM32\ntdll.dll': Shared library architecture i386:x86-64 is not compatible with target architecture i386.
warning: `C:\Windows\SYSTEM32\wow64.dll': Shared library architecture i386:x86-64 is not compatible with target architecture i386.
warning: `C:\Windows\SYSTEM32\wow64win.dll': Shared library architecture i386:x86-64 is not compatible with target architecture i386.
warning: `C:\Windows\SYSTEM32\wow64cpu.dll': Shared library architecture i386:x86-64 is not compatible with target architecture i386.
warning: Could not load shared library symbols for WOW64_IMAGE_SECTION.
Do you need "set solib-search-path" or "set sysroot"?
warning: Could not load shared library symbols for WOW64_IMAGE_SECTION.
Do you need "set solib-search-path" or "set sysroot"?
warning: Could not load shared library symbols for NOT_AN_IMAGE.
Do you need "set solib-search-path" or "set sysroot"?
warning: Could not load shared library symbols for NOT_AN_IMAGE.
Do you need "set solib-search-path" or "set sysroot"?
[New Thread 4184.0x13c0]
warning: `C:\Users\Dominik\Desktop\SAMP Realistic DM\msvcp110.dll': Shared library architecture i386:x86-64 is not compatible with target architecture i386.
[New Thread 4184.0xa3c]
[New Thread 4184.0xad4]

Program received signal SIGSEGV, Segmentation fault.
0x0000002b in ?? ()

[Mellnik]

Never tried gdb on Windows but can you type in "bt" somewhere?

[Dominik523]

Yeah, I can write bt and it says no stack. After the server crashes, when I click on the window of the gdb, it closes instantly. So I can't write bt after the crash. This also came in the log file of the gdb if it helps anyhow:

Exception condition detected on fd 0
error detected on stdin
EOF [assumed Y]

[samp-incognito]

That won't do you much good anyway since you're (presumably) not using a version of the plugin compiled with debug symbols. The best way to debug on Windows isn't with GDB, but with the Visual Studio debugger. You'll need to compile the plugin with the debug configuration and attach the debugger to the SA-MP server process (https://msdn.microsoft.com/en-us/library/3s68z0b3.aspx).

That aside, if anything, it's probably YSF causing the crash and not the streamer plugin. It didn't crash for me when I tested it, but I haven't tried the latest YSF version.

[ghost]

For me it doesn't crash, BUT, do not work properly and that caused by streamer plugin, not YSF. I tested it 5 times, see below the reason:

I tested it with default samp ferris wheel script. If base object, where you want to attach objects didn't created, then objects which you want to attach will disapper. You need somehow create queue to first create base model, then attach attachable objects, because now it's based on draw distance. Now only fix is set base model draw distance to very high, then attachable objects very low.

[Mellnik]

After Dominik523 giving me his server files I did some debugging. I found the crash location to be in sampgdk.

The call stack:

And the crash location in sampgdk_native_invoke_array:

I've sent a crash dump and necessary files to Incognito.

[ikkentim]

'These are plugins that I use: plugins sscanf Whirlpool crashdetect streamer mysql'

AFAIK you need YSF to use that function

[samp-incognito]

@kurta999: I don't see anything specifically wrong with the way it's implemented now. You just have to be mindful of the streaming distances, which only really applies when you have a base object that is very large (as in your case with the ferris wheel). For that matter, other factors could cause the objects to not attach correctly, like one of the objects being in a different virtual world. I could change this behavior and force all of the attached objects to stream irrespective of streaming distance, but this might not always be desired. I'll have to think about it.

@Mellnik: Thanks for this.

@ikkentim: Yeah, I didn't even catch that he wasn't running YSF.

I would guess, then, that FindNative is returning null, which is making InvokeNative crash, though I figured InvokeNative would have some kind of internal check for that. I could add one myself, which should resolve the problem, assuming this is what's actually causing the crash. Actually, a warning that YSF is not loaded should probably be added too.

[ikkentim]

@samp-incognito sampgdk does indeed not check whether the specified native is null.

[Crayder]

Incognito - 
    I could change this behavior and force all of the attached objects to stream irrespective of streaming distance, but this might not always be desired.

Not absolutely relative but this would actually be wonderful. Currently what I do with attached objects is set their default stream distance to 0 and when the parent object is streamed in for a player I set the stream distance for that child object higher. This is not very efficient but you could do way better than this method.

[karimcambridge]

So the problem here is that the attached objects are being streamed before the parent object thus crashing a crash since the parent object isn't created yet?

[samp-incognito]

@Kar2k: No, this crash is occurring when YSF has not been loaded.