[ECOS] sscanf --> CYG_ASSERTCLASS( this, "Stream object is not a valid stream!" ) is failing

Adolfo Lucha Adolfo.Lucha@controlware.de
Mon May 26 17:51:00 GMT 2003


I  faced a problem while calling sscanf(). Let me explain the constellation:

I have two threads. One of them writes periodically to a file with the sequence fopen, fwrite, fclose. The file is placed in the flush. I integrated the Tevero Flush File System in eCos.

The other thread, calls in correlation to external events which occurs also periodically but asynchronous,   the sscanf() function. The sscanf() function transform all the arguments and afterwards, unnecessarily because there are no more fields to be converted, it calls refill(). Refill calls cyg_libc_stdio_flush_all_but() where it comes to call *stream->flush_output_unlocked()*. In flush_output_unlocked() the macro CYG_ASSERTCLASS( this, "Stream object is not a valid stream!" ) is failing.

I am debugging that problem view days. I think it can be of two natures: A wrong pointer is corrupting the memory or there are some lock/unlock problems while accessing the file array present in Cyg_libc_stdio_files class. I read suspect :-) comments in cyg_libc_stdio_flush_all_but() function about lock/unlock mechanism.

Other observation: When the debugger stopped at the mentioned assert point, the stream object points to an object where the member magic_validity_word contains different values. Some time it contains 0xBADBAD and some times it contains other unpredictable values. Because of the first appearance I fell that it can be a lock/unlock problem, because it should never occur. The code 0xBADBAD is written explicite in two methods: dtor() and initialise(). The unpredictable contents suggest me the presence of a spurious pointer (which I still do not found).

I am of course compiling with CYGSEM_LIBC_STDIO_THREAD_SAFE_STREAMS defined.

One thread is using fopen() while the other is calling open(). But I think it does not matter. Mix of both layers should be possible is not it?

The second thread is opening the file, as mentioned, using open() and keeping it open for lifetime of the thread.

Workaround: Because I do not understand why it is still crashing I done a dirty workaround. I added some space to the buffer given as first parameter to the sscanf() function. That avoids the call to refill and consequently the call to flush_output_unlocked(). It works but it is not really a solution.

Hints will be appreciated.


Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

More information about the Ecos-discuss mailing list