lseek function applied on open disk crashes my program.
 

I open a disk using
int f= open(devicename,O_RDWR);
then I want to seek to a position. Here it is 0( could be anything).
lseek(f,0,SEEK_SET);

After this I want to write something. The device name is /dev/sdc ( a disk, it could be sda, sdb anything).

But just after lseek is executed, I get a coredumped message on the command prompt.

If I omit lseek, I can go on writing and after closing, can see the data. But I need lseek. Note that lseek64 also creashes the same way.

Am I doing something silly? Please help.
Basudeb

Did you confirm if the file is opening properly, what is the value of "f" after open ?

I actually continued writing without using lseek, took out the disk, connected in another machine and verified that write was done correctly.
But if I add lseek even once, there is no error return, it just crashes out saying core dumped. I have tried it in two versions of Fedora 16 32 bit and 64 bit with the same result.

Additional information: If I write the same code in a test.c file, compile and run it, it works fine. But as my program runs with wxWidgets, I need to compile it in wxWidgets environment. Asking this question in wxWidgets forum did not fetch any response. Is it an issue of g++ or wxWidgets? Why should lseek create core dump?

Can you run program that crashed under strace and post results?

I am attaching the strace done on the following code:

int sector_size;
char *buf;
int n = 1;

int fd = open("/dev/sdc", O_RDONLY|O_NONBLOCK); //O_NONBLOCK is an afterthought
//the problem happens without it
if(fd<0)
wxMessageBox(L"error in opening /dev/sdc");
else
wxMessageBox(L"success in opening /dev/sdc");
ioctl(fd, BLKSSZGET, &sector_size);
wxMessageBox(L"sector_size=" + INTtoCSTR(sector_size)); // INTtoCSTR is a function written in another cpp
lseek(fd, n*sector_size, SEEK_SET);

buf = malloc(sector_size);
int32_t readbytes= read(fd, buf, sector_size);
wxMessageBox(L"read count=" + INTtoCSTR(readbytes));
close(fd);
wxMessageBox(L"test over");
return false;

The only lseek that I found in your strace output was on the usr/share/icons/Adwaita/cursors/xterm file.

I don't think that lseek on disk was ever executed.

I find the same code working fine with both gcc and g++ if I do not link to wxWidgets. After getting your response, I also checked and found ioctl (8,...) after that it is all unknown functions and finally a Segmentation fault.

It appears to me the lseek function is somehow modified by wxWidgets library and then there is some bug; so it is never calling the actual lseek function.

Assuming it is so, how do I get around this and call actual system lseek function at this point? Is it possible?

It's strange. I don't think that wxWidget library do such a thing as modify lseek.
Could you run your crashed program under strace -i and under ltrace?

I am attaching the ltrace -i file, starting from the open function.

I would simplify it, it cannot be handled easily. I tried now ltrace -C that will give a bit more info about system calls:
try a really simple test, like this:
replace printf with wxMessageBox one by one, also try to debug, probably it does not reach lseek at all....

Well, I did not use main() I did it in OnInit which is the starting point of wxApp Class.
Attached is the ltrace. It clearly shows that at lseek, the code simply vanishes.

Please note that if I put the same code in a separate program and compile it either using gcc or g++, there is no problem at all.

So, I still think it is wxWidgets which is doing something funny.

it looks like wxWidgets has its own seek, wxSeek (filefn.h) - and also wxOpen and other file operations. Probably you can try to stop after preprocessing and see what was generated (that is -E for gcc).

But that is the question: Why should my program crash, if I call lseek function? It is a system function.
I think wxSeek is defined in wxWidgets as

#define wxSeek wxPOSIX_IDENT(lseek)

I have not got any answer in wxwidgets forum on this. Anyhow, is there any way to get around this? How do I bypass wxWidgets for lseek function?

Yes, there is, but you need to go thru the other possibilities also: have you tried to debug it and step into lseek? Have you tried wxOpen/wxSeek, probably works. Have you tried to catch the result of preprocessing and see what was generated? Have you tried ltrace with -C to see if the real low level seek (SYS_lseek) was called?
Do you have a stack trace of the coredump?