@kas1e

Quote:
Hmm, I was hoping that would help. Can you at least move the window to the proper location with MoveWindow() or ChangeWindowBox() after it's been opened?

@kas1e

Perhaps WA_AutoAdjust is altering the location of your window? Here's what the autodocs have to say about it:

Quote:
Since you're not using a NewWindow, WA_AutoAdjust defaults to TRUE. It might be confused by the double-height screen, and ends up putting the window where it thinks it's visible. Try adding WA_AutoAdjust, FALSE, and see if that helps.

@kas1e

I'd assume that for compatibility reasons malloc() uses MEMF_SHARED. If it didn't, you'd expect to get a DSI when some other task/thread tried to access the semaphore.

Quote:
You could also allocate the entire isem_t using AllocVecTags(), instead of just the SignalSemaphore. That way, you wouldn't need to change any of the other semaphore code to work with pointers to objects instead of embedded objects (I assume you made those changes when you tested Andrea's suggestion).

SignalSemaphores (and Lists) can also be allocated using AllocSysObjectTags(), which presumably initializes them for you. You'd again be working with pointers to objects.

I suspect that none of that will make a difference, but it might be worth a try if further debugging doesn't turn up anything.

Quote:
It sounds like they're suggesting that if we have a working implementation of std::counting_semaphore (do we?) that we could look at the source code for that and see how it's implemented compared to how libpsem did it.

@kas1e

Quote:
Ah, so it doesn't have the history behind it that I was expecting. Still, from at least a casual examination of the code, I don't see anything that looks like it would cause a major system lockup, as long as it's getting valid data to work with. That's not the same as saying I'm sure there's nothing wrong with it, but I'd still check those other two possibilities first.

Quote:
Having a working debugger would be nice, though a hard system crash would probably kill the debugger, too.

Unfortunately, there's no simple way to check for the first possibility (corruption of the underlying sem_t). The sem_t contains embedded Exec SignalSemaphore and List structs, rather than pointers to them, so you'd need to DebugPrintF() a bunch of fields in those structs to try to determine if they are corrupt or not. You could at least dump isem->value and see if it looks reasonable (it should probably be zero).

You could also add some "made it to this point"-style DebugPrintF()s inside sem_post(), to try to determine where in that function the crash occurs.

For the second possibility (the code being triggered by the semaphore is what crashes) you'd need to locate the code that's waiting on the semaphore that's being posted to; something like "m_send_sleep_semaphore.wait()". Then you could add some "made it to this point"-style DebugPrintF()s both before and after the wait, to see if the code actually exits the wait before the crash occurs. If it does, you can move the DebugPrintF()s further along in the code to try to narrow down where the crash happens.

@kas1e

The code for sem_post() isn't terribly complicated. Since the same code seems to work most of the time (and presumably in other projects as well), I'm guessing that's not where the problem lies. So two possibilities come to mind.

1. The semaphore (sem_t) that's being passed to sem_post() is getting clobbered by something. sem_post() makes a number of Exec calls, passing pointers obtained from the semaphore. If one or more of those pointers is invalid, it could potentially cause a crash.

2. Presumably there's another thread somewhere that's sem_wait()ing on the semaphore. That thread wakes up when sem_post() posts to the semaphore, and that thread does something that causes the crash. The crash is not caused by the post, it's just triggered by it.

@kas1e

Quote:
num is given a default value of 1 in the declaration of Semaphore:


So if you call post() without a parameter it should use the default. You could add a printf to confirm that.

The problem is probably in the call to sem_post(&semaphore);.

@trixie

Hey, E-mu! I applied for a job there once, way back when.

SnoopDos does have a nicer user interface, though that's no help if the basic functionality doesn't work.

One SnoopDos feature I really miss on Snoopy is the ability to easily enable or disable all of the function monitors. When first starting to debug something and I have no idea what's wrong I often like to enable everything, and then disable selected functions afterwards if logging them gets in the way. That was one button on SnoopDos, but involves manually selecting a slew of items across multiple submenus with Snoopy.

It would be nice if there were "Enable All" and "Disable All" menu selections, at least for the DOS Functions menu. And perhaps a "Default Settings" (or "Saved Settings") selection as well, to easily get back to the starting point.

@ktadd

I found this one some years ago, and it's always worked well for me: testmy.net

@Raziel, @walkero

Quote:
Yes, that's exactly what I did.

The bug seems to be something that's rarely encountered, since it's been around for some time (it was in at least the previous version of the SDK (53.30), too).

I believe I've stumbled across a bug in one of the newlib header files (the ones from the most recent SDK). I was trying to compile GIFLIB, where one of the files has the following bit of code:


It compiled fine when using clib2, but when using newlib I got the following error when SIZE_MAX was referenced:


The file indeed does not include <limits.h>, but it does include <stdint.h>. The clib2 version of <stdint.h> contains the following:


So <stdint.h> includes <limits.h>, and everything works fine. The newlib version of <stdint.h>, however, contains the following:


In other words, <limits.h> is included only if the version of GCC is 3.2 or earlier. That seems odd, which makes me think that "#include <limits.h>" should come after the #endif, not before it.

I made this change, and was able to build GIFLIB without error. I recompiled a number of my other projects, and nothing seems to have been broken by the change. But the flow of system headers can be complex and difficult to follow, so I thought I'd see if others can confirm that this is a bug, or explain why it isn't.

@Raziel

Quote:
Ah, I see. You're right, when a numpad key that varies with the NumLock state is pressed, it's possible to deduce the state- if you get a '0' from the numpad then NumLock must be on, and if you get an 'Insert' it must be off.

That won't work with numpad keys like '5' and '+' that don't vary with the NumLock state though, and of course someone has to press a numpad key before you can update the state. That might be good enough, depending on what you're looking to do with the NumLock state, but it's not a general purpose way to know the current state.

@Capehill
@Raziel

It looks like the numlock key does not generate a keycode on the Amiga. At least, when I run the Input Event Sniffer (http://os4depot.net/?function=showfil ... isc/inputeventsniffer.lha) and watch for RAWKEY and EXTENDEDRAWKEY events nothing happens when I press numlock.

Quote:
Given that, it would be good defensive programming practice to set 'status' to 0 before making the call, so if the call aborts without setting the status at all then at least you'll get a consistent failure, rather than a random result depending on what happens to be on the stack. That would have saved kas1e a lot of time playing with printf().

@kas1e

What if you put the printf() or Delay() at the very beginning of your function, before making any of the SDL calls? Does it work there? What if you put it at the very end, just before the "return SDL_TRUE;"? (Which means it won't even be called if compiling the shaders fails.) Or does it have to be in between the two sets of SDL calls in order to make a difference?

And what if you use IExec->DebugPrintF() rather than printf()?

I waited for a bit in case anything else came up, but nothing did. So I've released version 1.1 of Profyler, which adds a workaround for the bug in ObtainDebugSymbol() and so can now display the source file name and line number for every profiled function.

The workaround shuts off starting with Exec version 54.47, so hopefully the bug fix will be present in that version when it appears.

@kas1e

Remember that while printf() looks simple in the source code, there's a lot going on under the hood, involving the console (which decides where the printed text goes), the graphics library (which renders the font characters into pixels), and the graphics card driver (which gets the pixels to the screen).

Somewhere in all of that there's almost certainly something that has to Wait(), which gives other tasks a chance to run. So printf() doesn't just take some time to execute. but it also allows other tasks to run. Your for() loop takes time, but most likely doesn't cause a task switch (assuming the delay isn't so long that it's preempted). Calling Delay() of course also allows other tasks to run, without all the other complexity of printf().

I'm not a 3D graphics guru, so I have no idea what those graphics calls are doing. But if it involves another task that's running asynchronously, then letting that task run while you're delaying may give it a chance to complete some necessary work that doesn't get done in time otherwise.

@LiveForIt

It's not precisely what you asked for, but the autodoc for version.library has this table for the version number of version.library itself:

@walkero

I saw this same thing once a few days ago, when visiting as a guest (not logged in)- news items from 2006 or 2007, and if I scrolled down to the bottom of the home page the page selection buttons had me on some page number in the hundreds, instead of page 1.

I don't remember what I did to fix it- I think I just clicked on 'Home', but I may be remembering wrong. I imagine I could have clicked on the page 1 button, too.

I haven't seen the problem since, so it's not readily reproducible.

@geennaam

Any chance I could get a copy of your benchmark program? I'm curious what the X1000 numbers would be.