After excessive logging there seems to be a stack corruption happening somewhere in here.
Sometime in the next calls after the file is compressed, usually in the plugin providing the ftp upload native, it's erroring out.
Log:
Spoiler
Quote:
L 11/06/2012 - 23:18:10: [wcfansourcetvmanager.smx] Start recording stv_1352240290_cs_italy_wcfan2010.dem
L 11/06/2012 - 23:28:10: [wcfansourcetvmanager.smx] Stopped recording stv_1352240290_cs_italy_wcfan2010.dem. (enc: 073132589788f2eba4ce14c33fc02304, start: 1352240290, end: 1352240890, cheater: 0, banned: 0
L 11/06/2012 - 23:28:10: [wcfansourcetvmanager.smx] Start recording stv_1352240890_cs_italy_wcfan2010.dem
L 11/06/2012 - 23:28:15: [wcfansourcetvmanager.smx] Compressing file stv_1352240290_cs_italy_wcfan2010.dem from demos/stv_1352240290_cs_italy_wcfan2010.dem to demos/stv_1352240290_cs_italy_wcfan2010.dem.bz2
L 11/06/2012 - 23:28:17: [wcfansourcetvmanager.smx] Compressed file stv_1352240290_cs_italy_wcfan2010.dem (073132589788f2eba4ce14c33fc02304) from demos/stv_1352240290_cs_italy_wcfan2010.dem into demos/stv_1352240290_cs_italy_wcfan2010.dem.bz2.
L 11/06/2012 - 23:28:17: [wcfansourcetvmanager.smx] Deleting uncompressed file demos/stv_1352240290_cs_italy_wcfan2010.dem
L 11/06/2012 - 23:282: [wcfansourcetvmanager.smx] Uploaded file stv_1352240290_cs_italy_wcfan2010.dem from demos/stv_1352240290_cs_italy_wcfan2010.dem.bz2 to /56/073132589788f2eba4ce14c33fc02304 (start: 1352240290, end: 1352240890, cheater:
L 11/06/2012 - 23:282: [wcfansourcetvmanager.smx] Deleting uploaded file demos/stv_1352240290_cs_italy_wcfan2010.dem.bz2
L 11/06/2012 - 23:292: [wcfansourcetvmanager.smx] Stopped recording stv_1352240890_cs_italy_wcfan2010.dem. (enc: 443a7739afef2a850ab42376d244b050, start: 1352240890, end: 1352240972, cheater: 0, banned: 0
L 11/06/2012 - 23:297: [wcfansourcetvmanager.smx] Compressing file stv_1352240890_cs_italy_wcfan2010.dem from demos/stv_1352240890_cs_italy_wcfan2010.dem to demos/stv_1352240890_cs_italy_wcfan2010.dem.bz2
L 11/06/2012 - 23:297: [wcfansourcetvmanager.smx] Compressed file stv_1352240890_cs_italy_wcfan2010.dem (443a7739afef2a850ab42376d244b050) from demos/stv_1352240890_cs_italy_wcfan2010.dem into demos/stv_1352240890_cs_italy_wcfan2010.dem.bz2.
L 11/06/2012 - 23:297: [wcfansourcetvmanager.smx] Deleting uncompressed file demos/stv_1352240890_cs_italy_wcfan2010.dem
L 11/06/2012 - 23:40:00: [wcfansourcetvmanager.smx] Backup: Uploading file demos/stv_1352240890_cs_italy_wcfan2010.dem.bz2 to /56/443a7739afef2a850ab42376d244b050
L 11/06/2012 - 23:40:02: [wcfansourcetvmanager.smx] Uploaded file stv_1352240890_cs_italy_wcfan2010.dem from demos/stv_1352240890_cs_italy_wcfan2010.dem.bz2 to /56/443a7739afef2a850ab42376d244b050 (start: 1352240890, end: 1352240972, cheater:
L 11/06/2012 - 23:40:02: [wcfansourcetvmanager.smx] Deleting uploaded file demos/stv_1352240890_cs_italy_wcfan2010.dem.bz2
Error log:
Spoiler
Quote:
L 11/06/2012 - 23:297: [SM] Plugin encountered error 17: Stack memory leaked by native
L 11/06/2012 - 23:297: [SM] Native "MarkNativeAsOptional" reported:
L 11/06/2012 - 23:297: [SM] Displaying call stack trace for plugin "ftp.smx":
L 11/06/2012 - 23:297: [SM] [0] Line 94, ftp.sp::OnGameFrame()
The FTP_UploadFile native is called in the bz2 callback. I first thought it's been a problem with your tEasyFTP plugin, then thought it might be an issue with the cURL extension (that's why it's no longer teasyftp.smx but the ftp protocol in sp using the socket extension), but the error still persisted.
Now when comparing the timestamps, it seems it's getting weird in this bzip2 extension.
The only thing i've noticed with my limited c++ knowledge is a basic parameter count error in the forward creation (2 should be 4), but that didn't help too.
Maybe it doesn't like that i'm compressing a file every 10 minutes or in this example shortly in 1 minute?
No need to look at curl anymore;) Hope you've got some time to proof read for some subtle leaks?
Edit:
Are you even using the g_pAsyncCallback forward? Looks like you're just populating it - and do a direct call afterwards.
Another typo which might be causing this in the CompressFile native. you're casting the compressionlevel to a funcid ;)
I'll test and report back.