[SOLVED] lseek function applied on open disk crashes my program.

basudebg · 06-21-2012, 04:35 AM

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

bsat · 06-22-2012, 02:00 AM

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

basudebg · 06-22-2012, 02:06 AM

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.

basudebg · 06-22-2012, 02:30 AM

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?

Valery Reznic · 06-22-2012, 03:13 AM

Quote:

Originally Posted by basudebg

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?

basudebg · 06-22-2012, 03:37 AM

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;

Valery Reznic · 06-22-2012, 05:01 AM

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.

basudebg · 06-22-2012, 05:28 AM

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?

Valery Reznic · 06-22-2012, 11:30 PM

Quote:

Originally Posted by basudebg

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?

basudebg · 06-24-2012, 11:02 AM

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

pan64 · 06-24-2012, 11:37 AM

I would simplify it, it cannot be handled easily. I tried now ltrace -C that will give a bit more info about system calls:

PHP Code:



open("/dev/sdc1", 2048, 036145107030 <unfinished ...> 
SYS_open("/dev/sdc1", 2048, 036145107030)                                       = 3 
<... open resumed> )                                                            = 3 
puts("success opening /dev/sdc" <unfinished ...> 
SYS_fstat(1, 0x7ffff1948bc0)                                                    = 0 
SYS_mmap(0, 4096, 3, 34, 0xffffffff)                                            = 0x7faac15d9000 
SYS_write(1, "success opening /dev/sdc\n", 25success opening /dev/sdc 
)                                  = 25 
<... puts resumed> )                                                            = 25 
ioctl(3, 4712, 0x7ffff1948d0c <unfinished ...> 
SYS_ioctl(3, 4712, 0x7ffff1948d0c, 0, 0xffffffff)                               = 0 
<... ioctl resumed> )                                                           = 0 
lseek(3, 512, 0 <unfinished ...> 
SYS_lseek(3, 512, 0)                                                            = 512 
<... lseek resumed> )                                                           = 512 
close(3 <unfinished ...> 
SYS_close(3)                                                                    = 0 
<... close resumed> )                                                           = 0 
SYS_exit_group(0 <no return ...>

try a really simple test, like this:

Code:

int main()
{
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) {
    printf("error in opening /dev/sdc");
    exit (1);
    }
else
    printf("success in opening /dev/sdc");
ioctl(fd, BLKSSZGET, &sector_size);
printf("sector size: %i\n", sector_size);
lseek(fd, n*sector_size, SEEK_SET);

close(fd);
return 0;
}

replace printf with wxMessageBox one by one, also try to debug, probably it does not reach lseek at all....

basudebg · 06-24-2012, 12:12 PM

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.

pan64 · 06-24-2012, 12:31 PM

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).

basudebg · 06-24-2012, 12:54 PM

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?

pan64 · 06-24-2012, 01:07 PM

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?