Re: [hatari-devel] Fwrite warnings

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ] 

Hi Uwe,
I posted patches for suppressing consecutive repeated messages (identical ones) to another mail thread. 

On 27.10.2022 14.47, Uwe Seimet wrote:

Thank you for fixing this. There is a different kind of warning (not new),
which I doubt should be on warning level:

WARN : No GEMDOS dir '/home/us/TT/F/C/LOCAL/INCLUDE/OTHER'
WARN : No GEMDOS dir '/home/us/TT/F/C/LOCAL/INCLUDE/other'

IMO it is normal that Pure C (or other compilers) try to access
non-existing folders while searching for files on the include path. From
that perspective debug or trace level would probably be more adequate.
Programs compiled with MiNTlib can do even more accesses to (MiNT specific) paths that are missing / not relevant under TOS (timezone etc). 

However, I think that:
* files not being at expected paths is the most common reason why programs do not work [1], and * that is good enough reason tolerate a bit of noise from Hatari, as it cannot know which of those misses are actual problems 

What the others think?
[1] E.g. if user gives program directly to Hatari for auto-starting (= C: is dir where program is), but program expects to find its files with absolute paths that include program's directory name.
Btw. I'm now wondering why there aren't more complaints about the mass of warnings Hatari shows on every startup, due to (Emu)TOS HW checks at bootup: 
----------------------------------
WARN : Bus Error reading at address $4fffff, PC=$e00d76 addr_e3=e00d76 op_e3=4a10 WARN : Bus Error reading at address $ffffa200, PC=$e00d76 addr_e3=e00d76 op_e3=4a10 WARN : Bus Error reading at address $400000, PC=$e00d76 addr_e3=e00d76 op_e3=4a10 WARN : Bus Error reading at address $6c4710, PC=$e00d76 addr_e3=e00d76 op_e3=4a10 WARN : Bus Error reading at address $5d1234, PC=$e00d76 addr_e3=e00d76 op_e3=4a10 WARN : Bus Error reading at address $6d3148, PC=$e00d76 addr_e3=e00d76 op_e3=4a10 WARN : Bus Error reading at address $400000, PC=$e00d76 addr_e3=e00d76 op_e3=4a10 WARN : Bus Error reading at address $d003c3, PC=$e00d76 addr_e3=e00d76 op_e3=4a10 WARN : Bus Error reading at address $cc03c3, PC=$e00d76 addr_e3=e00d76 op_e3=4a10 
----------------------------------


	- Eero



Best regards

Uwe


Hi,

On 27.10.2022 10.08, Uwe Seimet wrote:

Yes, that fixed has helped. All warnings are gone.


Thanks, I pushed slightly updated version of it.

Before next release this message can be downgraded to DEBUG log level,
but for now I want to keep it at WARN log level to catch potential
further issues with it.



In general it might be a good idea to suppress consecutive duplicate
warnings but just to display them once with a count, e.g.

WARN : GEMDOS Fwrite() to 'ROOT.O' file, opened as read-only (3 times)


I have patches out on the mailing list to do that for trace output, but
I could extend it to cover also log messages.

Because suppression logic adds some overhead and can delay output of the
identical messages a lot, it's behind a new "--repeat-limit" Hatari
debug option.


	- Eero


instead of

WARN : GEMDOS Fwrite() to 'ROOT.O' file, opened as read-only
WARN : GEMDOS Fwrite() to 'ROOT.O' file, opened as read-only
WARN : GEMDOS Fwrite() to 'ROOT.O' file, opened as read-only

Best regards

Uwe


Hi Uwe,

On 27.10.2022 0.39, Eero Tamminen wrote:

On 26.10.2022 15.16, Uwe Seimet wrote:

with the latest sources I get tons of warnings when, for instance, I
compile
with Pure C. I have never seen these warnings before.

WARN : GEMDOS Fwrite() to 'ROOT.O' file, opened as read-only


This is from following commit:
https://git.tuxfamily.org/hatari/hatari.git/commit/?id=799020b84d0224a4bb38f2b892a8ecdd1c11bcc1



Is this a bug or can these warnings be switched off? There are so
many of
them that it's hard to see the actually relevant messages.

   >
   > I just noticed that I also get these warnings
   > for files definitely opened for writing, i.e.
   > opened with fopen(FILENAME, "w") with Pure C.

Can you provide GEMDOS trace around that warning?


Only case where I can see this happening:
* Fwrite() done for a FD from Fcreate(), not Fopen(), and
* That FD number being reused from an earlier, already Fclose()d,
read-only Fopen() call


Attached patch should fix that.  Does it help?


	- Eero



diff --git a/src/gemdos.c b/src/gemdos.c
index 1c3e4010..5067ac54 100644
--- a/src/gemdos.c
+++ b/src/gemdos.c
@@ -896,6 +896,8 @@ static void restore_file_handle_info(int i, FILE_HANDLE *handle)
   		fclose(fp);
   		return;
   	}
+	/* used only for warnings, ignore those after restore */
+	handle->bReadOnly = false;
   	handle->FileHandle = fp;
   }
@@ -2021,8 +2023,11 @@ static bool GemDOS_Create(uint32_t Params) 
   		 * - GEMDOS_FILE_ATTRIB_WRITECLOSE   (FA_ARCHIVE)
   		 *   (set automatically by GemDOS >= 0.15)
   		 */
+		FileHandles[Index].bReadOnly = false;
   		if (Mode & GEMDOS_FILE_ATTRIB_READONLY)
   		{
+			/* enable write warnings */
+			FileHandles[Index].bReadOnly = true;
   			/* after closing, file should be read-only */
   			if (chmod(szActualFileName, S_IRUSR|S_IRGRP|S_IROTH))
   			{
@@ -3883,8 +3888,9 @@ void GemDOS_Info(FILE *fp, uint32_t bShowOpcodes)
   	{
   		if (!FileHandles[i].bUsed)
   			continue;
-		fprintf(fp, "- %d (0x%x): %s\n", i + BASE_FILEHANDLE,
-			FileHandles[i].Basepage, FileHandles[i].szActualName);
+		fprintf(fp, "- %d (0x%x): %s (%s)\n", i + BASE_FILEHANDLE,
+			FileHandles[i].Basepage, FileHandles[i].szActualName,
+			FileHandles[i].bReadOnly ? "ro" : "rw");
   		used++;
   	}
   	if (!used)

Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/