Deprecated: mysql_connect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead in /storage/content/49/145849/famitracker.com/public_html/forum/classes/dbHandler.php on line 29
FamiTracker
all of a sudden I've started getting a page fault every time I start famitracker. It's even more confusing how it affects both windows and linux/wine, but only famitracker versions newer than (not including) 0.3.7...
I have absolutely no idea what causes it. I tried deleting the famitracker key in the registry entries (windows) and the wine dotfolder (full reinstall), no change. Heck, I even tried setting the time back like two months in case it was date related
[url=http://ocv.me/dump-ft041-01.zip]Here's the windows minidump and wine output.
Hopefully it's something obvious and not my ram acting up...
I've actually seen this several times now. FamiTracker tries to load the plugins supplied with NSFplay as export plugins and fails. The solution is to move NSFplay to a separate directory.
I checked this earlier because an invalid plugin should not crash the program, but this seems to be on NSFplay's side so I don't think there's much I can do about it.
Hey rainwarrior, I was gonna notify you once I had more information about it. The problem is that the crash seems to be completely random each time and occurs in the famitracker EXE, the only clue is that one of NSFplay's DLL files is still in the list of loaded DLLs (famitracker should unload all DLLs that are not valid plugins) and that I can reproduce it by placing the DLL files in the plugins directory.
I don't know much more at the moment unfortunately. I took a quick look at the DLL sources and it seems that LoadLibrary is called from one of the DllMain functions, that is usually not allowed but I'm unsure if it should cause crashes like that, especially since NSFplay itself works fine. It may explain the unloaded DLL however.
Ah, could be that it has its UI in a separate DLL for some reason. It looks like nsfplug_ui.dll does get LoadLibrary'd from DllMain of in_yansf.ini.
So... I guess that's a bug that's been in NSFPlug since who knows when. Perhaps FamiTracker ends up loading nsfplug_ui.dll first, presuming it's a plugin, and then when in_yansf.ini tries to load it a second time in its DllMain this causes a problem? I wonder how Winamp avoids this crash... When FamiTracker loads nsfplug_ui.dll and fails to find the plugin functions, does it unload it right away, or does it load them all at once before unloading non-plugins? (Or maybe Winamp ignores any DLL that doesn't start with "in_"?)
On my end, it'd probably be best to try and merge nsfplug_ui.dll into in_yansf.ini and not have to deal with the extra DLL load. I've never liked how it's two separate DLLs.
It should unload the DLL right away and continue looking for files. I guess windows has an internal reference counter to keep track on how many times a DLL has been loaded.
I checked this a bit more and apparently there is a delete ui; line in in_nsf.cpp that will free the UI DLL on unload, but it is commented out. Adding that line again actually fixes the problem, but I assume that was removed for a reason so I don't know what the side effects are.
Still I have no idea why leaving this file loaded would crash the tracker, I haven't been able to debug that at all. Somehow it corrupts the memory or something.
