Ok so I decided to mess around with Ubuntu in Windows 11 lately. Started out with Ubuntu 22.04.5 LTS and just did its base g++ install and other needed things to compile. Then of course got the mud to compile error free and when I ran it and went to log in it would always crash the mud. It always seems to be the same issue and while I have managed to get around this crash the thing is it will just go until the next crazy thing it doesn't like and crash again. So currently I have g++-11 (installed) g++-12(installed) and g++-13(installed) all compile clean but 12 and 13 will both crash for the exact same thing. Im open to suggestions and hopefully someone else has already figured out the issue.

(gdb) bt
#0  __pthread_kill_implementation (no_tid=0, signo=6, threadid=) at ./nptl/pthread_kill.c:44
#1  __pthread_kill_internal (signo=6, threadid=) at ./nptl/pthread_kill.c:78
#2  __GI___pthread_kill (threadid=, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#3  0x00007ffff7dd026e in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#4  0x00007ffff7db38ff in __GI_abort () at ./stdlib/abort.c:79
#5  0x00007ffff7db47b6 in __libc_message_impl (fmt=fmt@entry=0x7ffff7f59765 "*** %s ***: terminated\n")
    at ../sysdeps/posix/libc_fatal.c:132
#6  0x00007ffff7ec1c19 in __GI___fortify_fail (msg=msg@entry=0x7ffff7f5974c "buffer overflow detected")
    at ./debug/fortify_fail.c:24
#7  0x00007ffff7ec15d4 in __GI___chk_fail () at ./debug/chk_fail.c:28
#8  0x00007ffff7ec2db5 in ___snprintf_chk (s=s@entry=0x555555818ee2  "",
    maxlen=maxlen@entry=65, flag=flag@entry=2, slen=slen@entry=63, format=format@entry=0x5555557029bb "%02x")
    at ./debug/snprintf_chk.c:29
#9  0x00005555556b6079 in snprintf (__fmt=0x5555557029bb "%02x", __n=65,
    __s=0x555555818ee2  "") at /usr/include/x86_64-linux-gnu/bits/stdio2.h:54
#10 sha256_crypt (pwd=pwd@entry=0x7fffffffdb70 "omitted") at sha256.c:331
#11 0x0000555555622807 in con_get_account_pass (d=d@entry=0x55555596e710,
    argument=argument@entry=0x7fffffffdb70 "omitted") at comm.c:1788
#12 0x00005555556230a8 in con_get_name (d=d@entry=0x55555596e710, argument=argument@entry=0x7fffffffdb70 "omitted")
    at comm.c:2225
#13 0x00005555556232b5 in nanny (d=d@entry=0x55555596e710, argument=argument@entry=0x7fffffffdb70 "omitted")
    at comm.c:2297
#14 0x0000555555625654 in game_loop () at comm.c:677
#15 0x0000555555625bd6 in main (argc=, argv=) at comm.c:482

I haven't messed with any of this stuff in awhile, but it would appear there's some issue with the SHA256 module since that's the last codebase related function that was called before the crash. You appear to be using a different SHA 256 module than the one currently included in SmaugFUSS since the one in FUSS only has 221 lines in it.

I have gcc 13.2 installed on my server at the moment and have been meaning to test compile stuff on it to see what kinds of errors or warnings the compiler spits out these days.

Once I fixed that part it let me log into the account then log into a character and on flush buffer it crashed on showing the amount of gold on the character. Haven't actually tested out the smaugfuss yet I'll compile and try it today see if it does some crazy crashing as well.

well looks like it doesn't crash on SmaugFUSS1.9.4 even though looks the same almost on mine
this is in LOP sha256.c

char *sha256_crypt( const char *pwd )
{
   SHA256_CTX context;
   static char output[65];
   unsigned char sha256sum[32];
   unsigned int j;

   SHA256_Init( &context );
   SHA256_Update( &context, (const unsigned char *) pwd, strlen(pwd) );
   SHA256_Final( sha256sum, &context );

   for( j = 0; j < 32; ++j )
   {
      snprintf( output + j * 2, sizeof( output ), "%02x", sha256sum[j] );
   }
   return output;
}

in smaugfuss1.9.4 it is

char *sha256_crypt( const char *pwd )
{
   sha256_ctx ctx;
   static char output[65];
   unsigned char sha256sum[32];
   unsigned int j;

   sha256_init( &ctx );
   sha256_update( &ctx, ( const unsigned char * )pwd, strlen( pwd ) );
   sha256_final( &ctx, sha256sum );

   for( j = 0; j < 32; ++j )
   {
      snprintf( output + j * 2, 65, "%02x", sha256sum[j] );
   }
   return output;
}

I will say only seems to be 2 things that mine crashes on that sha256_crypt snprintf and the display_prompt for gold lol for whatever reason the slen is smaller than the maxlen which causes it to want and close. get past them though it seems to run fine lol.

ok so on display_prompt

//                  snprintf( pbuf, sizeof( buf ), "%s", show_char_gold( ch ) );
                  mudstrlcpy( pbuf, show_char_gold( ch ), sizeof( buf ) );

don't know why the snprintf will crash but the mudstrlcat won't it does the same as the sha256 though where slen is lower than max so it tries to close it all out.

and the sha256 this seems to get by the issue as well

char *sha256_crypt( const char *pwd )
{
   SHA256_CTX context;
   char buf[65];
   static char output[65];
   unsigned char sha256sum[32];
   unsigned int j;

   SHA256_Init( &context );
   SHA256_Update( &context, (const unsigned char *) pwd, strlen(pwd) );
   SHA256_Final( sha256sum, &context );

   output[0] = '\0';
   for( j = 0; j < 32; ++j )
   {
      snprintf( buf, sizeof( buf ), "%02x", sha256sum[j] );
      mudstrlcat( output, buf, sizeof( output ) );
//      snprintf( output + j * 2, sizeof( output ), "%02x", sha256sum[j] );
   }
   return output;
}

Probably not related, but in the SHA256 file you have, the parameters for sha256_final are backward.

The module itself was something I found on a website rather than something anyone on a MUD team wrote. It's never misbehaved itself like this before.

lol go figure it matches the way its listed in mine though

void SHA256_Final(unsigned char digest[32], SHA256_CTX * ctx)

I have no clue what was up with those very two simple snprintfs though but it didn't like them at all lol. (wonder how many more it doesn't like I just haven't had it try and use)

Yep, I realized it later after having downloaded LOP to see which one you had. That's the old copy of the module that turned out to not be generating correct hashes for the standard. It's why it got replaced in FUSS.

Seems as though you have a deeper problem if you're getting buffer issues on the descriptor reads in comm.c.

ah so I should probably update it in LOP as well ty yea i have no clue it just seems to be those two places at least for now. is an odd one though.

lol so since they are fairly easy to replace I just replaced the sha256 with the ones from smaugfuss no issues.... right back to that crash though lol

#10 sha256_crypt (pwd=pwd@entry=0x7fffffffdb70 "sy95c2h5") at sha256.c:217
217           snprintf( output + j * 2, 65, "%02x", sha256sum[j] );

same thing it is showing slen as 63 and maxlen as 65 and down it goes. lol ive reinstalled the g++ already so im guessing its just got to be changed how i had the other one for now haha

so for what ever reason any kind of snprintf in display_prompt will crash mine and the way the sha256 is will as well on any snprintf some odd stuff going on haha.

Not sure why LOP isn't liking me doing the display_prompt like smaugfuss does but oh well i just made a tempbuf and snprintf it to the tempbuf instead and at the end mudstrcat it into the pbuf and it solved the display_prompt issues lol.

for (size_t j = 0; j < 32; j++) {
    snprintf(output + j * 2, 3, "%02x", sha256sum[j]);
}

output[64] = '\0';

That should fix the snprintf issue :R

I'd be very hesitant to alter the code in such a widely distributed package like that without knowing for an absolute certainty that it's a bug. If it's a bug, then it should get reported to the author assuming they're still maintaining it.

Well I will say that it did for sure take care of the snprintf issue Elwood lol. Did you notice that about the same issue in all of my display_prompt you might have an idea on? it uses a char *pbuf = buf; then snprintf into that pbuf will cause the same kind of crash. however i used a tempbuf and snprintf all the stuff into it and then mudstrcat it into pbuf and solved the issue.