today, i wanted to try out my test arabic gtk program to see if behdad's new changes to pango magically fixed the renown arabic shaping issue [in short, it had nothing to do with it]. anyway, i discovered that i needed to install libquran, and to make a long story short, my test program, which used to work before, segfaulted. i ran gdb and valgrind only to find the segfault happening within libquran at the closing of the configuration file (noting this libquran code hasn't been changed in 3 years now).
i looked at the source, and discovered that the file pointer was becoming null after a call to getline. i tried to see if i could reproduce this in a smaller test program, and i discovered that i indeed could -
please click here to see the program code, i am tired of trying to get the formatting right with igSyntaxHiliter and/or with the wp code editor, and i am also tired of dealing with dreamhost not letting me post an fopen function call because mod_security flags it as an emergency error and returns a 503...
the program displayed the first line from testfile, but unexpectedly displayed that fp is null and segfaulted at the fclose. checking the return from getline, i see that it returns successfully (the number of characters it read).
while i got around this problem by modifying the library to do a malloc followed by an fgets, i am just confused -this library code hasn't been touched in 3 years, it used to work before, and i just repulled it from cvs when i discovered this. so why is it broken now? the only thing that i can think of being different is that my box now runs a 64 bit version of linux, but would that break it?
any ideas?
Tags: c
“now fp is: not null”
i compiled your code and didn’t have that problem
try initializing tmp with NULL, since getline only allocates memory if the pointer is NULL… or better yet malloc it yourself and give it to getline.
thanks for your response -
so setting tmp to NULL didn’t fix it. however, malloc before calling getline results in the file pointer being preserved. seems as though maybe getline is having an issue allocating the buffer, but why?
by the way, the output of valgrid [short version] is:
==20776== Invalid read of size 2
==20776== at 0x4B82483: getdelim (in /lib64/libc-2.5.so)
==20776== by 0x40061F: main (broken.c:7)
==20776== Address 0x0 is not stack'd, malloc'd or (recently) free'd
so getline calls getdelim and getdelim is broken on x86_64?
Salaam,
I have a prayer timing widget idea for Vista. Any ideas on how I can get access to a databse/pool of comprehensive prayer timings to cities all around the world, or at least North America?
Jazak’Allah,
Jamal.
contact me at: jamal.saq [at] gmail.com
yup, seems as though its related to which libc you compile against… one of my friends found that the tls libc breaks while the normal one doesn’t - will report here if i find out anything else.
No problem with this test code under RHEL 4.3 (libc-2.3.4) on x86_64.
However, for a complete test, you should also provide the content of “testfile”.