LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

User Interface Lib "Input/Output Error" (-93)

Hello,
 
sometimes, the Ini_WriteToFile funcion returns a -93 Error. This is described as "Input/Output Error" The -93 is defined as UIEIOError in the userint.h file.
Does anybody know what acutally causes this error?
I'm using CVI 8.01.
 
Thanks,
Greg
0 Kudos
Message 1 of 8
(4,206 Views)

Ini_WriteToFile function uses a couple of functions that can generate this error. The error returned is the originalone generated by these functions except for a call to fflush whose possible errors are remapped from the original value of errno variable.

In any case, since this tool is distributed at source code level you can examine this function in detail and check for possible causes. Maybe the best way to do this is to load the instrument in the Instrument menu instead of the library menu, then execute Edit >> Attach and edit source function in the same menu and then put some conditional breakpoints trapping error < 0 condition in the disk-access functions included in Ini_WrtiteToFile function.



Proud to use LW/CVI from 3.1 on.

My contributions to the Developer Community
________________________________________
If I have helped you, why not giving me a kudos?
0 Kudos
Message 2 of 8
(4,186 Views)

Hello Roberto,

thanks for your reply. Unfortunately this problem happens not here on my system but at a customer who uses the compiled application. I was just wondering that "Input/Output Error" was listed as "Among the more commonly encountered errors are:" in the description of the Ini_WriteToFile function

All other erros in that list have a clear understandable meaning, whereas "Input/Output error" seems a bit undefined...

Among the more commonly encountered errors are:

–12 Out of memory!
–91 Too many files are open.
–93 Input/Output error.
–94 File not found.
–95 File access permission denied.
–97 Disk is full.
–99 File already open.
–100 Badly formed pathname.
–5003 Could not generate an unused temporary file name in the same directory as the output file.
–5004 Could not create a temporary file in the same directory as the output file.

 

So if it is a commonly encountered error for this function, there should be a defined meaning behind it as it is for all other erros in that list.


Best Regards,

Greg

 

 

0 Kudos
Message 3 of 8
(4,167 Views)

Any statement from NI to this problem?

Thanks,
Greg

 

0 Kudos
Message 4 of 8
(4,141 Views)
Whenever the ini file instrument encounters an error that reports through errno (error in an ANSI C function), it calls a function to translate that error into a CVI specific error code. The following function (from inifile.c) does this job:


static int Ini_GetErrCodeFromWriteErrno(int errnoVal, int forceError)
{
    switch (errnoVal)
        {
        case 0:
            return forceError ? UIEIOError : UIENoError;
        case EPERM:
        case EACCES:
            return UIEAccessDenied;
        case ENOMEM:
            return UIEOutOfMemory;
        case ENOSPC:
            return UIEDiskFull;
        case EBUSY:
        case EIO:
        case ENXIO:
            return UIEIOError;
        default:
            return UIEIOError;
        }
}


If you need more granularity in detecting this error, you have a few options.

1. You could attach the .ini instrument for debugging, and simply place a breakpoint in this function and examine the value of errno encountered. This would also allow you to look up the stack for the exact location of the problem and possibly gain some insight from that.

2. You could modify this function (for example, to log the exact value of errno, or print it to stderr) and recompile the instrument object and your project.

Something like this:

static int Ini_GetErrCodeFromWriteErrno(int errnoVal, int forceError)
{
    switch (errnoVal)
        {
        case 0:
            if (forceError)
            {
                fprintf(stderr, "Unknown error occured; not reported through errno.\n");
                return UIEIOError;
            }
            return UIENoError;
        case EPERM:
        case EACCES:
            return UIEAccessDenied;
        case ENOMEM:
            return UIEOutOfMemory;
        case ENOSPC:
            return UIEDiskFull;
        case EBUSY:
            fprintf(stderr, "Device or resource busy");
            return UIEIOError;
        case EIO:
            fprintf(stderr, "I/O Error");
            return UIEIOError;
        case ENXIO:
            fprintf(stderr, "No such device or address");
            return UIEIOError;
        default:
            fprintf(stderr, "Unspecified error occured; errno = %d. Lookup this error code in errno.h.", errnoVal);
            return UIEIOError;
        }
}

Hope this helps,

-alex
0 Kudos
Message 5 of 8
(4,131 Views)
Hello Alex,
 
thanks for your help. As mentioned, this problem happens at a customer installation. Debugging with a new installation would not be easy.
 
However, let's  assume I would be able to, and let's assume that the errnoVal value would be either:
 
EBUSY (Device or resource busy)
or
EIO (I/O Error)
 
what would be the appropriate advice to the customer for each condition to fix that problem?
 
Best Regards,
Greg
 
 
0 Kudos
Message 6 of 8
(4,127 Views)
EIO typically only occurs if there is a physical problem with the media being read or written (bad sectors, a scratched CD, etc.). There are some other instances where it could occur, but they are fairly rare. It is sort of a fall back error indicating something bad has happened and the OS may not know exactly what. EBUSY simply indicates that multiple things are trying to read or modify something and the relevant device doesn't support it. It typically occurs with removable media (ie. a floppy disc, CD) but can occur in other circumstances (trying to delete a directory that has locked files in it, etc.). I could also forsee possible strange behavior that could result in either error when trying to operating on a single file from multiple threads or processes, but that's just speculation at this point.
Message 7 of 8
(4,118 Views)
Thanks a lot Alex, that gives me a pointer at what to look for!
 
Best Regards,
Greg
 
0 Kudos
Message 8 of 8
(4,107 Views)