Programming thread -

[Gorilla Tessellator]

I came here to whine a bit.

I usually try to find mistakes in my code, guided by a principle that you should not blame others, but instead try to find fault in yourself. It works beautifully in real life, but not if you deal with other people's crappy code. 9/10 this week I lost hours on fixing bugs that were in other people's code.
I guess I have to tweak my principle a bit.

/whining

 

[Least Concern]

I came here to whine a bit.

I usually try to find mistakes in my code, guided by a principle that you should not blame others, but instead try to find fault in yourself. It works beautifully in real life, but not if you deal with other people's crappy code. 9/10 this week I lost hours on fixing bugs that were in other people's code.
I guess I have to tweak my principle a bit.

/whining

Is there some reason why you can't just notify the other person (I'm assuming this is a co-worker) of the issues you found with their code and have them fix it?

 

[ConcernedAnon]

Nope you misunderstand. The code block is just an example of kernel coding. What I was talking about was scheduling. The fact you use C# is kinda amusing, be eh, you get the scheduling for free, now don't you.

https://en.wikipedia.org/wiki/Scheduling_(computing)#Windows

Didn't I tell you I was being an asshole in that post, also know as shitposting.

I get that the OS schedules things as it sees fit, but that was not particularly relevant to my original argument, which was simply that you need not create a new process in order to do concurrent work. True, 16 threads doesn't mean 16 cores utilized, however, it does mean that the OS is free to run your program concurrently if it pleases, and would you know it, it does please! Or at the very least, 12 times the speed pleases me.

Additionally, looking at profiling data I found that windows is generally relatively reluctant to let a single program use the whole processor —which is fair enough— generally granting my test program between 16-30% utilization, even with 16 threads, but that nonetheless represents a grant of more than one core. Messing with the number of threads/steps, I found that if pushed, windows could be coerced into granting 100% utilization to the test program, which interestingly lead to a near 16x speed gain. Seemingly it decides "if you really need it" based on how well you are filling your current time slice. Use the whole thing and you get more, yield halfway through and you get less, at least that's my presumption.

Is there some reason why you can't just notify the other person (I'm assuming this is a co-worker) of the issues you found with their code and have them fix it?

Maybe they can't be trusted to, the code was just that horrific. Because gotos are evil, they were using exceptions as flow control —why is shit like this suggested on stack overflow pajeet pls

 

[SIGSEGV]

exceptions as flow control

That sounds absolutely niggerlicious.

 

[Yotsubaaa]

That sounds absolutely niggerlicious.

>not saying "That sounds absolutely exceptional." (zing!)
You had one job, man.

I came here to whine a bit.

I usually try to find mistakes in my code, guided by a principle that you should not blame others, but instead try to find fault in yourself. It works beautifully in real life, but not if you deal with other people's crappy code. 9/10 this week I lost hours on fixing bugs that were in other people's code.
I guess I have to tweak my principle a bit.

/whining

That sounds awful (but typical). I can commiserate: I spent the entire day reworking some graphs in a client report because the original author had fucking nondeterministic code that swapped ML classifications on a whim, and the rest of the analysis and report was written just assuming that 1="positive" and 2="negative" always, without actually checking/correcting.

 

[SIGSEGV]

>not saying "That sounds absolutely exceptional." (zing!)
You had one job, man.

God is not the architect of such confusion.

 

[Kosher Dill]

That sounds absolutely niggerlicious.

void print(const char* s)
{
    const char *err = "Null pointer passed in", *p;

    __try
    {
        p = &(*s);
    }
    __except(MY_NULLPTR_EXN_FILTER(GetExceptionInformation()))
    {
        p = err;
    }
    __finally
    {
        printf("%s\n", p);
    }
}

 

[SIGSEGV]

void print(const char* s)
{
    const char *err = "Null pointer passed in", *p;

    __try
    {
        p = &(*s);
    }
    __except(MY_NULLPTR_EXN_FILTER(GetExceptionInformation()))
    {
        p = err;
    }
    __finally
    {
        printf("%s\n", p);
    }
}

>exceptions
>in C
>just to check for a NULL pointer
That's pretty niggerlicious.

 

[Kosher Dill]

I was going to use a triangle fill as the example but I just couldn't get it working no matter what I did

 

[Gorilla Tessellator]

Is there some reason why you can't just notify the other person (I'm assuming this is a co-worker) of the issues you found with their code and have them fix it?

I have to avoid power-level. Let me just add that this person is higher in company organization hierarchy.
Of course I do notify about the bugs I found regularly. However, it makes me feel bad not only because of the wasted time, but also because he is supposed to be better than me, and I feel I should restrain myself not to look like I'm trying to undercut him or something.

 

[Piss Clam]

void print(const char* s)
{
    const char *err = "Null pointer passed in", *p;

    __try
    {
        p = &(*s);
    }
    __except(MY_NULLPTR_EXN_FILTER(GetExceptionInformation()))
    {
        p = err;
    }
    __finally
    {
        printf("%s\n", p);
    }
}

That doesn't actually help out of try catch block. That's why you replace the top level exception handlers with your own and do a stack walk with the exception pointers. Do you know what a map file is? Just curious.

 

[Kosher Dill]

That doesn't actually help out of try catch block.

Who said anything about "helping"?
When I'm not competing for the Terry A. Davis Memorial Scholarship For Afro-American Informatics I'll usually just have the top-level handlers flip SEH exceptions over into the C++ system and deal with them all there. Never tried anything more clever than that.

Do you know what a map file is?

Kinda-sorta but I've never needed to use one myself and I couldn't tell you anything about how SEH implementations use their own maps. So, do tell.

EDIT: and by the way, I looked it up and apparently HolyC does have exception handling. That vaguely surprises me.

 

[Piss Clam]

Who said anything about "helping"?
When I'm not competing for the Terry A. Davis Memorial Scholarship For Afro-American Informatics I'll usually just have the top-level handlers flip SEH exceptions over into the C++ system and deal with them all there. Never tried anything more clever than that.


Kinda-sorta but I've never needed to use one myself and I couldn't tell you anything about how SEH implementations use their own maps. So, do tell.

Well you are missing the ball game, bro. Map files will help you out in release builds when you are developing with other idiots who don't know how to Unit Test, and then your nigger ass gets called up to debug it.

There are two top level handlers if you are writing C++ and lets say Visual C++/WinNT

https://docs.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-setunhandledexceptionfilter

Issuing SetUnhandledExceptionFilter replaces the existing top-level exception filter for all existing and all future threads in the calling process.


The exception handler specified by lpTopLevelExceptionFilter is executed in the context of the thread that caused the fault. This can affect the exception handler's ability to recover from certain exceptions, such as an invalid stack.


/QUOTE]

_set_se_translator

The _set_se_translator function provides a way to handle Win32 exceptions (C structured exceptions) as C++ typed exceptions. To allow each C exception to be handled by a C++ catch handler, first define a C exception wrapper class that can be used, or derived from, to attribute a specific class type to a C exception. To use this class, install a custom C exception translator function that is called by the internal exception-handling mechanism each time a C exception is raised. Within your translator function, you can throw any typed exception that can be caught by a matching C++ catch handler.


You must use /EHa when using _set_se_translator.


To specify a custom translation function, call _set_se_translator using the name of your translation function as its argument. The translator function that you write is called once for each function invocation on the stack that has try blocks. There is no default translator function.


Your translator function should do no more than throw a C++ typed exception. If it does anything in addition to throwing (such as writing to a log file, for example) your program might not behave as expected, because the number of times the translator function is invoked is platform-dependent.

At the Kernel level one of the last call before you see that "blue screen of death" which isn't what we call it called KeBugCheck(...) or KeBugCheckEx(...). I'd suggest if you want to learn more is to download windbg from microsoft, and install it. Then read some of the help and do some kernel debugging. One thing that might help you on a dump file is hitting !analyze -v. It will give you the best guess...you should also set up your symbol server such as:

_NT_SYMBOL_PATH=fSymbols;srv*fServerSymbols*http://msdl.microsoft.com/download/symbols


The first are my private symbols for development the second is the download server from mickey soft.


Now onto map files. I'll just post someone's write up of it. You should really use them if you are a programmer/developer or whatever you want to call yourself.


This is old shit, but map files have been around a long time, so I don't think anything has changed

Finding Crash Information Using the MAP File

Finding crash information using the MAP file: how to create and read the file

www.codeproject.com

 

[Kosher Dill]

This is old shit, but map files have been around a long time, so I don't think anything has changed

https://www.codeproject.com/Articles/3472/Finding-Crash-Information-Using-the-MAP-File

......
Yeah OK, this is much more convenient than what I had to do the last time this kind of thing came up.
1. Note the crash address
2. Load up the executable again in the debugger and figure out what module the crash was in based on the modules' address ranges
3. Load that module in Dependency Walker and find what function that address was in, based on the exports' address ranges
4. Use psychic powers to guess why that function could have crashed


About handlers: I was familiar with _set_se_translator but I'm not immediately seeing what practical use there is for SetUnhandledExceptionFilter.

 

[Piss Clam]

......
Yeah OK, this is much more convenient than what I had to do the last time this kind of thing came up.
1. Note the crash address
2. Load up the executable again in the debugger and figure out what module the crash was in based on the modules' address ranges
3. Load that module in Dependency Walker and find what function that address was in, based on the exports' address ranges
4. Use psychic powers to guess why that function could have crashed


About handlers: I was familiar with _set_se_translator but I'm not immediately seeing what practical use there is for SetUnhandledExceptionFilter.

Well in my day and maybe this has changed, but if a C++ exception is thrown then it won't be caught by any SE top level handler. They are two different types.

You can redirect a C style SE into C++ but as far as I know (back in the day) you couldn't reverse that, because C and C++ are two different languages and while C++ is aware of C, C has no clue what C++ is.

This is why you didn't really want to use C++ to write kernel code because the DDK linker and memory management were really different than your standard VC++/SDK shit. You could go down that path, but you'd have to disassembly your code to make sure it was doing what it was suppose to do. It was kinda frowned on back in the day, so kernel/driver level code we wrote in C and the rest in C++...such as it was.

 

[Kosher Dill]

You can redirect a C style SE into C++ but as far as I know (back in the day) you couldn't reverse that

Yeah, this is still true as far as I'm aware.

On the general topic of "exceptions as flow control" - supposedly Microsoft Excel used SEH to handle sparse memory allocation for spreadsheets. It would just go ahead and assume a page of memory had been allocated from the process heap for whatever cells you were working on, and then if that triggered an exception, the handler would go and allocate a page.

 

[Piss Clam]

Yeah, this is still true as far as I'm aware.

On the general topic of "exceptions as flow control" - supposedly Microsoft Excel used SEH to handle sparse memory allocation for spreadsheets. It would just go ahead and assume a page of memory had been allocated from the process heap for whatever cells you were working on, and then if that triggered an exception, the handler would go and allocate a page.

Oh man you just triggered me *lol* I'm of the camp you only use an exception when you want to bring the program or system down, but I worked for this large corporation where people loved to throw exceptions. I'm like what are you fucking retarded? We got contractors and temps here. You think they know when they call your code that you are going to throw and exception in the bowels of it. Does everything now have to be a try catch block.

 

[ConcernedAnon]

Yeah, this is still true as far as I'm aware.

On the general topic of "exceptions as flow control" - supposedly Microsoft Excel used SEH to handle sparse memory allocation for spreadsheets. It would just go ahead and assume a page of memory had been allocated from the process heap for whatever cells you were working on, and then if that triggered an exception, the handler would go and allocate a page.

That's actually a reasonable usage tbf. If I'm not mistaken, memory paging works on a similar principle anyway. If the program accesses memory outside of the mapped set a page fault occurs, but as long as that memory access was valid, the corresponding page is loaded by the OS and the segmentation fault is suppressed. The initial validity checks are done by hardware, and so it's "free" in that the cost of signal handling only occurs if a page fault actually occurs, and the cpu doesn't have to perform any extra logic until that happens.

At the end of the day though, that kind of thing is still an "exceptional" case so I'd say it's reasonably appropriate, though I can imagine that it complicates things. When I brought it up I was thinking of jackasses suggesting exceptions as a way of breaking out of nested loops. There's this ritualistic aversion to gotos and so some people(?) —classification of these creatures is pending— seem to end up with the idea that an exception is preferable. On a related note, the only good thing about java is it's continue/break expressions. They cover the common use cases for gotos, but in a much more acceptable and structured way.

 

[Least Concern]

I have to avoid power-level. Let me just add that this person is higher in company organization hierarchy.
Of course I do notify about the bugs I found regularly. However, it makes me feel bad not only because of the wasted time, but also because he is supposed to be better than me, and I feel I should restrain myself not to look like I'm trying to undercut him or something.

I get it. That does sound like an awkward situation. I've been fortunate that whenever my superiors have been coders themselves, they've been at least as good as me, and in one case far better and we had a good sort of apprentice/master relationship going on. But if I were in a situation like yours, I'd also probably just silently fix their code and hope they get Peter Principled to another team or something. I actually kinda like the whole puzzle-solving aspect of bug-fixing anyway, and a paycheck is a paycheck.

 

[Chad Nasty]

I came here to whine a bit.

I usually try to find mistakes in my code, guided by a principle that you should not blame others, but instead try to find fault in yourself. It works beautifully in real life, but not if you deal with other people's crappy code. 9/10 this week I lost hours on fixing bugs that were in other people's code.
I guess I have to tweak my principle a bit.

/whining

I don't know what you mean by bugs, if they got past any code review process and integrated into a prod environment that's a bad thing.

But, I've worked environments (like a fortune 500 company) where I have to do things in stupid ways because a DBA doesn't allow this or some product leads giving me requirements I need to work because full-stack development in huge companies that involves all product teams sometimes requires you to do "creative" problem solving you know will be a problem later but have the BA saying it needs to be done ASAP.