> I don't notice any cases of where a stale file descriptor is being
> accessed. I'm stumped :-/
Can it be a problem with clone() calls? AFAIK, it's how SQLite checks
if it can work safely from multiple threads. Martin, can you recompile
SQLite with SQLITE_THREADSAFE set to 0 and look if your pinging will
work with that?
BTW, what OS are you using, what compiler and what is your compilation command?
Also it would be interesting to see strace results when your
successful pinging is made before sqlite3_close() and when
unsuccessful pinging is made after statement execution.
Pavel
On Wed, Mar 24, 2010 at 11:45 AM, David Baird <dhba...@gmail.com> wrote:
> On Wed, Mar 24, 2010 at 9:24 AM, David Baird <dhba...@gmail.com> wrote:
>> On Wed, Mar 24, 2010 at 9:05 AM, Martin Sigwald <msigw...@gmail.com> wrote:
>>> While I could gather, both the open system called generated by the DB and
>>> the socket() syscall are returning a FD=3.
>>> That is, they are both trying to use the same filedescriptor. My guess is
>>> packets get sent to that file descriptor, instead of the port. How can I
>>> changed this? I just followed standar procedure to allocate a socket:
>>> sockfd = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP))
>>>
>>> Shouldn't the Kernel take care of this and provide an unused FD??
>>
>> According to the strace, the kernel is taking care of that properly.
>> You get a socket, call sendto, select, recvfrom, then close it. And
>> then you open guido.db. Since you just closed your socket, the fd=3
>> is reused for guido.db. This is perfectly legitimate. Something else
>> funny is going on. Here's the relevant portions from the strace:
>
> Actually, I just realized that a socket is opened twice in your
> strace. So, here's the portion that includes both socket opens and
> the database open:
>
> First socket open and close:
>
> socket(PF_INET, SOCK_RAW, IPPROTO_ICMP) = 3
> setsockopt(3, SOL_IP, IP_HDRINCL, [1], 4) = 0
> sendto(3, "E\0\34\0Eg\0\0\377\1P\223\0\0\0\0\n\0\0\3\10\0;\320#\306"...,
> 28, 0, {sa_family=AF_INET, sin_port=htons(0),
> sin_addr=inet_addr("10.0.0.3")}, 16) = 28
> select(4, [3], NULL, NULL, {2, 500000}) = 1 (in [3], left {2, 496000})
> recvfrom(3, "e\0\0\0...@\0\0@\0015\233\n\0\0\3\n\0\0\4\0\0C\320#\306"...,
> 28, 0, {sa_family=AF_INET, sin_port=htons(0),
> sin_addr=inet_addr("10.0.0.3")}, [16]) = 28
> fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xb7f16000
> write(1, "El Server 10.0.0.3 esta en el es"..., 43) = 43
> close(3) = 0
>
> Database open and close (with a dup in the middle that also creates fd=4)...
>
> getcwd("/home/martin", 5000) = 13
> open("/home/martin/guido.db", O_RDWR|O_CREAT|O_LARGEFILE, 0644) = 3
> fcntl64(3, F_GETFD) = 0
> fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
> fstat64(3, {st_mode=S_IFREG|0777, st_size=2048, ...}) = 0
> dup(3) = 4
> mmap2(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
> -1, 0) = 0xb7537000
> mprotect(0xb7537000, 4096, PROT_NONE) = 0
> clone(child_stack=0xb7d374c4,
> flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
> parent_tidptr=0xb7d37bd8, {entry_number:6, base_addr:0xb7d37b90,
> limit:1048575, seg_32bit:1, contents:0, read_exec_only:0,
> limit_in_pages:1, seg_not_present:0, useable:1},
> child_tidptr=0xb7d37bd8) = 6240
> mmap2(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
> -1, 0) = 0xb6d36000
> mprotect(0xb6d36000, 4096, PROT_NONE) = 0
> clone(child_stack=0xb75364c4,
> flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
> parent_tidptr=0xb7536bd8, {entry_number:6, base_addr:0xb7536b90,
> limit:1048575, seg_32bit:1, contents:0, read_exec_only:0,
> limit_in_pages:1, seg_not_present:0, useable:1},
> child_tidptr=0xb7536bd8) = 6241
> close(4) = 0
> _llseek(3, 0, [0], SEEK_SET) = 0
> read(3, "SQLite format 3\0\4\0\1\1\0@ \0\0\0\4\0\0\0\0"..., 100) = 100
> close(3) = 0
> getuid32() = 0
>
> And second socket open and close....
>
> socket(PF_INET, SOCK_RAW, IPPROTO_ICMP) = 3
> setsockopt(3, SOL_IP, IP_HDRINCL, [1], 4) = 0
> sendto(3, "E\0\34\0Hs\4\10\377\1I\177\0\0\0\0\n\0\0\3\10\0\276\256"...,
> 28, 0, {sa_family=AF_INET, sin_port=htons(0),
> sin_addr=inet_addr("10.0.0.3")}, 16) = 28
> select(4, [3], NULL, NULL, {2, 500000}) = 0 (Timeout)
> write(1, "TIMEOUT\n", 8) = 8
> close(3) = 0
>
>
> In both cases that you call sendto, it appears to have succeeded (i.e.
> because they returned a positive value, i.e. 28). In the second case,
> select timed out (as you said it does).
>
> I don't notice any cases of where a stale file descriptor is being
> accessed. I'm stumped :-/
>
> -David
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
