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
Another C0000005 (or whatever access violation was) crash bug.
But this only started happening after I overclocked.
I have a million dumps for this crash on slimeball's build, but, unfortunately, I can't post them and expect you to be able to use them, so I had to make a dump with "vanilla" 0.4.2
This only happens when I've used a lot of buffer and go to switch songs.
I've gotten more data on it. It's more common when the VRC6 or FDS is involved in the module change, and when you're switching chips. It also does NOT seem tied to buffers, as I thought before.
Worst-affected are modules with a frame return command set in. That is, switching out of them.
Also, even worse-affected are files hidden deep in an HDD's folder architecture. Example: This didn't actually happen to me until I started reinstalling windows, and had to move my massive famitracker folder onto another HDD. A well-organised HDD. The modules which experience this the most are from DemoCompo, which are all hidden on the sixth layer of folders, and the tracker has to navigate 4 times to reach them, no matter which version I use.
Considering what C0000005 is, and the nature of these crashes, it seems sort of like the tracker might be trying to read from the loaded file before it's loaded completely.
If you need more dumps from me, I could probably switch the forks off of my taskbar and use the main version temporarily to get some sweet, sweet dumps, though I'm not entirely sure it would be very quick.
[quote=SoltIW]Considering what C0000005 is, and the nature of these crashes, it seems sort of like the tracker might be trying to read from the loaded file before it's loaded completely.[/quote]
Unlikely at best. But it's sure a segmentation fault indeed.
Well, it's a seg fault, so, without any knowledge of how file loading works in famitracker, I'm going to say that the pointer for where the file begins in memory could possibly be re-assigned to a placeholder number which puts it in protected memory areas, until the file is fully loaded. But I don't know how loading in famitracker works, so I can't say that with any form of certainty. Also, I have no idea how the lower end of programming actually works, because I only touch high-level languages, so excuse me if that was pretty much the stupidest thing you've ever read.
Though, you know, there's a chance that the issue has to do with RAM latency compared to CPU or CPU-NB frequency, considering that the crashes are less common when I bring my RAM up with everything else, or bring everything else down to my RAM.[color=#3f3f3f] One might ask, wouldn't that be RAM SPEED? Well, if memory serves me correctly, and it often doesn't, RAM timings are in clocks, measured by the RAM clock rate. The faster the RAM's operating clock is, the lower the latency, even if timings remain the same. It'd more likely have to do with latency than speed, as excess latency is known to cause read and write errors, but excess speed is known to cause speedups.
Or, possibly, I'm just spewing minimal amounts of low-end knowledge onto my observations and trying to make sense of it without actually consulting any manuals, experts, or references.
Fortunately most computer programmers, even when using C or even assembler, don't have to know anything as specific as the RAM/CPU speed. File I/Os are handled by the OS, and it's next to impossible to access yet unread portion of the file, because the OS will not let you do this—basically, the read operation blocks until it is finished. In fact, how you handle file operations in the programming languages you know isn't much different of what it's done in FT in C++.
Segfaults are usually caused by out of bounds read/write access on an array (buffer overflow, for instance) or illegal accesses through a uninitialized/null/freed/corrupted pointer. If you have MSVC you can use the JIT debugger to know where this happened, though most of the time it isn't obvious why it segfaults—a buffer overflow can corrupt a pointer which, when latter used, causes a segfault; knowing where the buffer overflows occur requires using a write access breakpoint on said pointer and recreate the same initial conditions.
That's why jsr want to know how you trigger that segfault, it's because he can see why it crashed but to know why it happened he has to recreate the bug. The more precise it is, the better is.
[quote=SoltIW]But this only started happening after I overclocked[/quote]
I didn't see this the first time. The solution then is to not overclock your CPU.
