Bad File Descriptor

Bad File Descriptor

Scooter

Member #16,799

January 2018

Hi all:
I am having problems with textures returning 'Bad File Descriptor'.
It used to only happen when using Allegro5, but now it happens even
using the GLUT library. Does anyone have an answer for this problem?

Thanks for your time!

Edgar Reynaldo

Major Reynaldo

May 2007

We can't guess what you're doing. Show some code, like where you load your textures, any init code, etc...

Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide
King Piccolo will make it so Then I could just flip it with some sweet, sweet matrix math. In either case, I’ll ride this wagon until the wheels fall off. Thanks to those that keep it running

Scooter

Member #16,799

January 2018

Hi Edgar:
Hope all is well.
Please find cube.zip file above.
I sent two different C files.
The one cube.c compiles and displays perfect.
The one cubeX.c compiles and is screwed up.
Both files return 'Bad File Descriptor'.
The only difference between the two:
cubeX.c shows the code moved on the right side of the
braces in the drawCube function. Exactly the same files
except for that.

These are both done in Ubuntu Linux in Allegro5 using codeblocks compiler.

I get the same results using MX Linux 19.4.

I quit using Allegro because of this problem, but now it shows the
same problem in GLUT.

I checked the Internet and found this problem occurs in many programs.
Seems it is a kernel problem in applying a non negative number to files
being open or corrupt files. I have used these files for many years with
no problems until now.

Be interesting to see what you find out. I really need to use Allegro5
for this project.

As always, thanks for your time.

Edgar Reynaldo

Major Reynaldo

May 2007

Scooter - please explain a little more by what you mean when the files display "Bad File Descriptor". When does that happen? During compilation? During al_load_bitmap? During display code? You could try saving your files as UTF-8 in code blocks and see if that fixes it. I'm not sure where the error is coming from, as you say your first c file compiles and displays perfectly.

Scooter

Member #16,799

January 2018

Hi Edgar:
Did you compile and run the two C files?
On both files codeblocks returns 0 warnings and 0 errors.
I uploaded an image showing the 'Bad file descriptor' message
from codeblocks. Hope this helps.
Have a great day!

Edgar Reynaldo

Major Reynaldo

May 2007

It sort of works on Windows. No mention of any 'bad file descriptor' message. After fixing your includes and making it use OpenGL, cube.c displayed perfectly and ran fine. No compilation warnings or errors. cubeX.c (after the same fixes) displayed only 4 of the 6 colors, but otherwise ran fine.

I haven't tried it on Linux yet, but I will shortly.

It should be noted that you're both leaking memory and have dangling pointers. You overwrite the value of bmp without storing the old value to destroy later. Also, you shouldn't be calling glDeleteTextures, but rather al_destroy_bitmap. What's more, you haven't checked ANY return values to see if anything fails. Start there, save the file as UTF-8 and get back to me.

UPDATE
I tried it on Linux and it works exactly the same there. No mention of any 'bad file descriptor'.

Scooter

Member #16,799

January 2018

Hi Edgar;
I am running thru your last post! Very concerning about dangling pointers.
I declare (4) pointers: display, timer, event_queue and bmp. I set them all.
Where is the memory leak coming from?
Also, you say I did something with a bitmap and did not delete it later.
Please advise me on these items.

By the way, what is wrong with this site? I had to post this twice. The
first time it said it could not connect. Just wondering.

Anyway, Have a great day.

Edgar Reynaldo

Major Reynaldo

May 2007

This site is old and neglected. Talk to Matthew about it. ;/

Don't call glDeleteTextures. Allegro will take care of the textures by itself when the bitmap is destroyed. Allegro also destroys all bitmaps when the last display is destroyed. You can manually de-allocate the bitmaps using al_destroy_bitmap. This is where the memory leak is coming from. I was incorrect about dangling pointers.

Look at this example :

ALLEGRO_BITMAP* bmp = al_load_bitmap("green.jpg");
bmp = al_load_bitmap("blue.jpg");

The first value stored in the 'bmp' variable is overwritten and lost, hence the memory leak. If allegro wasn't tracking it in the background anyway.

I think the real problem is that you're calling glDeleteTextures. It means allegro will also try to destroy the textures when the display is destroyed. This is a double free, and leads to memory corruption.

UPDATE
In fact, it all makes sense. A GLuint is an unsigned non-negative number and in this case is a texture id. When allegro double destroys the texture, that is probably why it says bad file descriptor.

APPEND
Scooter, did this solve your problem?

Scooter

Member #16,799

January 2018

Hi Edgar:
This has been quite a job! My programs are fine as written. I happened to go to
Synaptic to download a program and it said I had broken files on the computer. I
clicked on 'Fix broken files' and nothing happened. So I stripped the computer and
loaded everything back on and things seem to be fine now. I brought out some older
computers and ran the files on them and all is well. This computer that gave me problems is fairly new to me. I started using it because it is much faster than the
one I was using. It came loaded with Windows 11, so I thought I was moving up, but
apparently that was NOT the case! I agree my programming needs much work but I think
it is still fun to try. Thanks for your help on this problem.

Have a great day!