Re: [sqlite] SQlite C API screwing port access?

[Martin Sigwald]

Will do. Thanks again to everyone. At least I learned how to use strace,
which I didnt no.

On Wed, Mar 24, 2010 at 2:25 PM, Pavel Ivanov  wrote:

> > When allocating memory for my ICMP packets I wasnt doind a bzero to fill
> all
> > fields with 0, so some "garbage" generated by Sqlite use of memory was
> > "corrupting" my packets.
>
> And still try please my very first suggestion - run you program with
> valgrind (just to get used to it and to use it right away next time).
> You'll see that it shows you all reading of uninitialized memory...
>
>
> Pavel
>
> On Wed, Mar 24, 2010 at 1:19 PM, Martin Sigwald 
> wrote:
> > Problem Solved: As some one point out, it was MY fault.
> > When allocating memory for my ICMP packets I wasnt doind a bzero to fill
> all
> > fields with 0, so some "garbage" generated by Sqlite use of memory was
> > "corrupting" my packets.
> > Thank you all for the help. One of the best user groups I ever met.
> Terrible
> > sorry for wasting your time.
> >
> > On Wed, Mar 24, 2010 at 2:12 PM, David Baird  wrote:
> >
> >> On Wed, Mar 24, 2010 at 11:09 AM, Martin Sigwald 
> >> wrote:
> >> > Doing N pings after a _close or a query has the same result as doind
> one:
> >> > not one of them works.
> >>
> >> Do 2 pings work ever?  For example, how about each of these scenarios?
> >>
> >> open_db
> >> ping
> >> ping
> >> close_db
> >>
> >> or
> >>
> >> ping
> >> ping
> >>
> >> or
> >>
> >> open_db
> >> close_db
> >> ping
> >> ping
> >>
> >> ?
> >>
> >> -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
> >
> ___
> 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

Re: [sqlite] SQlite C API screwing port access?

[David Baird]

On Wed, Mar 24, 2010 at 11:19 AM, Martin Sigwald  wrote:
> Problem Solved: As some one point out, it was MY fault.
> When allocating memory for my ICMP packets I wasnt doind a bzero to fill all
> fields with 0, so some "garbage" generated by Sqlite use of memory was
> "corrupting" my packets.
> Thank you all for the help. One of the best user groups I ever met. Terrible
> sorry for wasting your time.

Glad you found it ... forgetting to initialize data happens even to
the best of us sometimes.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQlite C API screwing port access?

[Pavel Ivanov]

> When allocating memory for my ICMP packets I wasnt doind a bzero to fill all
> fields with 0, so some "garbage" generated by Sqlite use of memory was
> "corrupting" my packets.

And still try please my very first suggestion - run you program with
valgrind (just to get used to it and to use it right away next time).
You'll see that it shows you all reading of uninitialized memory...


Pavel

On Wed, Mar 24, 2010 at 1:19 PM, Martin Sigwald  wrote:
> Problem Solved: As some one point out, it was MY fault.
> When allocating memory for my ICMP packets I wasnt doind a bzero to fill all
> fields with 0, so some "garbage" generated by Sqlite use of memory was
> "corrupting" my packets.
> Thank you all for the help. One of the best user groups I ever met. Terrible
> sorry for wasting your time.
>
> On Wed, Mar 24, 2010 at 2:12 PM, David Baird  wrote:
>
>> On Wed, Mar 24, 2010 at 11:09 AM, Martin Sigwald 
>> wrote:
>> > Doing N pings after a _close or a query has the same result as doind one:
>> > not one of them works.
>>
>> Do 2 pings work ever?  For example, how about each of these scenarios?
>>
>> open_db
>> ping
>> ping
>> close_db
>>
>> or
>>
>> ping
>> ping
>>
>> or
>>
>> open_db
>> close_db
>> ping
>> ping
>>
>> ?
>>
>> -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
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQlite C API screwing port access?

[Martin Sigwald]

Problem Solved: As some one point out, it was MY fault.
When allocating memory for my ICMP packets I wasnt doind a bzero to fill all
fields with 0, so some "garbage" generated by Sqlite use of memory was
"corrupting" my packets.
Thank you all for the help. One of the best user groups I ever met. Terrible
sorry for wasting your time.

On Wed, Mar 24, 2010 at 2:12 PM, David Baird  wrote:

> On Wed, Mar 24, 2010 at 11:09 AM, Martin Sigwald 
> wrote:
> > Doing N pings after a _close or a query has the same result as doind one:
> > not one of them works.
>
> Do 2 pings work ever?  For example, how about each of these scenarios?
>
> open_db
> ping
> ping
> close_db
>
> or
>
> ping
> ping
>
> or
>
> open_db
> close_db
> ping
> ping
>
> ?
>
> -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

Re: [sqlite] SQlite C API screwing port access?

[David Baird]

On Wed, Mar 24, 2010 at 11:09 AM, Martin Sigwald  wrote:
> Doing N pings after a _close or a query has the same result as doind one:
> not one of them works.

Do 2 pings work ever?  For example, how about each of these scenarios?

open_db
ping
ping
close_db

or

ping
ping

or

open_db
close_db
ping
ping

?

-David
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQlite C API screwing port access?

[Martin Sigwald]

Doing N pings after a _close or a query has the same result as doind one:
not one of them works.

On Wed, Mar 24, 2010 at 2:07 PM, David Baird  wrote:

> On Wed, Mar 24, 2010 at 9:42 AM, Martin Sigwald 
> wrote:
> > I meant socket. I know sockets are FDs. My mistake, sorry.
> > Yes, I tried putting the call before Sqlite calls and it works perfectly.
> If
> > I put it between open and close it works, provided I dont do anything
> else.
> > For example, if I open the DB, ping, then run a query then ping again,
> the
> > second ping wont work.
>
> What if you try doing two pings in a row?  Does the second ping ever
> work?  Does it always work?  Does it work sometimes?
> ___
> 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

Re: [sqlite] SQlite C API screwing port access?

[David Baird]

On Wed, Mar 24, 2010 at 9:42 AM, Martin Sigwald  wrote:
> I meant socket. I know sockets are FDs. My mistake, sorry.
> Yes, I tried putting the call before Sqlite calls and it works perfectly. If
> I put it between open and close it works, provided I dont do anything else.
> For example, if I open the DB, ping, then run a query then ping again, the
> second ping wont work.

What if you try doing two pings in a row?  Does the second ping ever
work?  Does it always work?  Does it work sometimes?
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQlite C API screwing port access?

[Martin Sigwald]

I'm attaching the strace output for the following code you asked:

int main(void){
sqlite3* db_handle=NULL;
if(sqlite3_open("guido.db",_handle))
{ //abro DB
fprintf(stderr,"Error while open
DB:%s\n",sqlite3_errmsg(db_handle));
printf("No pude abrir la DB\n");
exit(1);
}
 ping_pong("10.0.0.3",2);
 if(sqlite3_close(db_handle))
{
fprintf(stderr,"Error while open
DB:%s\n",sqlite3_errmsg(db_handle));
printf("No pude abrir la DB\n");
exit(1);
  }

return 0;
}

I' running Ubuntu 8.04, using gcc like this:
gcc ping.c main.c -o output.o -lsqlite3

How do I compile that with the threadsafe otpion you mentioned?

Thanks a lot for your help.
Martin


On Wed, Mar 24, 2010 at 1:09 PM, paivanof  wrote:

> > 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  wrote:
> > On Wed, Mar 24, 2010 at 9:24 AM, David Baird  wrote:
> >> On Wed, Mar 24, 2010 at 9:05 AM, Martin Sigwald 
> 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, 50}) = 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,

Re: [sqlite] SQlite C API screwing port access?

[paivanof]

> 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  wrote:
> On Wed, Mar 24, 2010 at 9:24 AM, David Baird  wrote:
>> On Wed, Mar 24, 2010 at 9:05 AM, Martin Sigwald  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, 50}) = 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, 50}) = 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 

Re: [sqlite] SQlite C API screwing port access?

[David Baird]

On Wed, Mar 24, 2010 at 9:24 AM, David Baird  wrote:
> On Wed, Mar 24, 2010 at 9:05 AM, Martin Sigwald  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, 50}) = 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, 50}) = 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

Re: [sqlite] SQlite C API screwing port access?

[Martin Sigwald]

I meant socket. I know sockets are FDs. My mistake, sorry.
Yes, I tried putting the call before Sqlite calls and it works perfectly. If
I put it between open and close it works, provided I dont do anything else.
For example, if I open the DB, ping, then run a query then ping again, the
second ping wont work.

On Wed, Mar 24, 2010 at 12:16 PM, Jay A. Kreibich  wrote:

> On Wed, Mar 24, 2010 at 12:05:58PM -0300, Martin Sigwald scratched on the
> wall:
> > 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))
>
>   BSD sockets are FDs.
>
>  What "port" are you talking about?  ICMP doesn't use ports.  Ports
>  are not interfaces.
>
>  I suggest you get a good book on networking programming and
>  debug your networking code.  There is very little chance this is an
>  SQLite issue.
>
>  Have you tried putting the ping call before the SQLite calls?
>  Between them?
>
>   -j
>
> --
> Jay A. Kreibich < J A Y  @  K R E I B I.C H >
>
> "Our opponent is an alien starship packed with atomic bombs.  We have
>  a protractor."   "I'll go home and see if I can scrounge up a ruler
>  and a piece of string."  --from Anathem by Neal Stephenson
> ___
> 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

Re: [sqlite] SQlite C API screwing port access?

[David Baird]

On Wed, Mar 24, 2010 at 9:05 AM, Martin Sigwald  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:

Socket is opened and closed here:

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, 50}) = 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

...and then database is opened here:

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
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQlite C API screwing port access?

[Jay A. Kreibich]

On Wed, Mar 24, 2010 at 12:05:58PM -0300, Martin Sigwald scratched on the wall:
> 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))

  BSD sockets are FDs.

  What "port" are you talking about?  ICMP doesn't use ports.  Ports
  are not interfaces.
  
  I suggest you get a good book on networking programming and
  debug your networking code.  There is very little chance this is an
  SQLite issue.

  Have you tried putting the ping call before the SQLite calls?
  Between them?

   -j

-- 
Jay A. Kreibich < J A Y  @  K R E I B I.C H >

"Our opponent is an alien starship packed with atomic bombs.  We have
 a protractor."   "I'll go home and see if I can scrounge up a ruler
 and a piece of string."  --from Anathem by Neal Stephenson
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQlite C API screwing port access?

[Martin Sigwald]

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??

On Wed, Mar 24, 2010 at 11:57 AM, Martin Sigwald  wrote:

> I tried using STRACE, unfortunately, I am quite new to Linux programming,
> so I can't make much sense out of the output. I attached it to this email,
> in case some kind soul would like to take a look at it.
> The program ran is exactly this:
>
> #include 
> #include 
> #include 
> #include "ping.h"
>
> int main(void){
> sqlite3* db_handle=NULL;
>
> ping_pong("10.0.0.3",2); //IP number + timeout in seconds --> This
> pings works fine
>
> if(sqlite3_open("guido.db",_handle))
> {
> fprintf(stderr,"Error while opening
> DB:%s\n",sqlite3_errmsg(db_handle));
> exit(1);
> }
>  if(sqlite3_close(db_handle))
> {
> fprintf(stderr,"Error while closing
> DB:%s\n",sqlite3_errmsg(db_handle));
> exit(1);
> }
> ping_pong("10.0.0.3",2); // This ping doesnt work
> return 0;
>
> }
>
> On Wed, Mar 24, 2010 at 4:51 AM, Roger Binns wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Martin Sigwald wrote:
>> > Here is the actual code:
>> >
>> > int main(void)
>> > {
>> > sqlite3* db_handle;
>> >
>> >  sqlite3_open(DB_NAME,_handle);
>> >  sqlite3_close(db_handle);
>> >  my_ping("10.0.0.4");
>> >
>> >   return 0;
>> > }
>> >
>> > If I call close after ping, it works. However, if besides of opening the
>> DB
>> > I perform any query, ping doesnt work either.
>>
>> My best guess is that you are making an error with file descriptors.  It
>> can be quite easy to accidentally use various values with low numbers
>> instead of the actual file descriptor numbers, and you'll get away with
>> it until some other code (eg sqlite) opens and closes files.  (Note that
>> under some circumstances SQLite can leave file descriptors open even
>> after close is called.)
>>
>> I suggest using strace and carefully examining the file descriptors used.
>>
>> Roger
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1.4.9 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>>
>> iEYEARECAAYFAkupxGUACgkQmOOfHg372QTd2ACeNaCEFII4TuVK8ZtTpCvZeFeX
>> ivYAnjuLh8uKl1z1jVauy9Fxa60Po9RR
>> =AVyR
>> -END PGP SIGNATURE-
>> ___
>> 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

Re: [sqlite] SQlite C API screwing port access?

[Martin Sigwald]

I tried using STRACE, unfortunately, I am quite new to Linux programming, so
I can't make much sense out of the output. I attached it to this email, in
case some kind soul would like to take a look at it.
The program ran is exactly this:

#include 
#include 
#include 
#include "ping.h"

int main(void){
sqlite3* db_handle=NULL;

ping_pong("10.0.0.3",2); //IP number + timeout in seconds --> This pings
works fine

if(sqlite3_open("guido.db",_handle))
{
fprintf(stderr,"Error while opening
DB:%s\n",sqlite3_errmsg(db_handle));
exit(1);
}
 if(sqlite3_close(db_handle))
{
fprintf(stderr,"Error while closing
DB:%s\n",sqlite3_errmsg(db_handle));
exit(1);
}
ping_pong("10.0.0.3",2); // This ping doesnt work
return 0;
}

On Wed, Mar 24, 2010 at 4:51 AM, Roger Binns  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Martin Sigwald wrote:
> > Here is the actual code:
> >
> > int main(void)
> > {
> > sqlite3* db_handle;
> >
> >  sqlite3_open(DB_NAME,_handle);
> >  sqlite3_close(db_handle);
> >  my_ping("10.0.0.4");
> >
> >   return 0;
> > }
> >
> > If I call close after ping, it works. However, if besides of opening the
> DB
> > I perform any query, ping doesnt work either.
>
> My best guess is that you are making an error with file descriptors.  It
> can be quite easy to accidentally use various values with low numbers
> instead of the actual file descriptor numbers, and you'll get away with
> it until some other code (eg sqlite) opens and closes files.  (Note that
> under some circumstances SQLite can leave file descriptors open even
> after close is called.)
>
> I suggest using strace and carefully examining the file descriptors used.
>
> Roger
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkupxGUACgkQmOOfHg372QTd2ACeNaCEFII4TuVK8ZtTpCvZeFeX
> ivYAnjuLh8uKl1z1jVauy9Fxa60Po9RR
> =AVyR
> -END PGP SIGNATURE-
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
execve("./miercoles.o", ["./miercoles.o"], [/* 22 vars */]) = 0
brk(0)  = 0x804b000
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xb7f17000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)  = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=49519, ...}) = 0
mmap2(NULL, 49519, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f0a000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
open("/usr/lib/libsqlite3.so.0", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20\316"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=410036, ...}) = 0
mmap2(NULL, 413188, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0xb7ea5000
mmap2(0xb7f08000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x62) = 0xb7f08000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260e\1"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1364388, ...}) = 0
mmap2(NULL, 1369712, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0xb7d56000
mmap2(0xb7e9f000, 12288, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x149) = 0xb7e9f000
mmap2(0xb7ea2000, 9840, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7ea2000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
open("/lib/tls/i686/cmov/libdl.so.2", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\n\0\000"..., 512) = 
512
fstat64(3, {st_mode=S_IFREG|0644, st_size=9684, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xb7d55000
mmap2(NULL, 12412, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0xb7d51000
mmap2(0xb7d53000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xb7d53000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or directory)
open("/lib/tls/i686/cmov/libpthread.so.0", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20H\0\000"..., 512) = 
512
fstat64(3, {st_mode=S_IFREG|0755, st_size=112354, ...}) = 0
mmap2(NULL, 94688, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0xb7d39000
mmap2(0xb7d4d000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 

Re: [sqlite] SQlite C API screwing port access?

[Roger Binns]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Martin Sigwald wrote:
> Here is the actual code:
> 
> int main(void)
> {
> sqlite3* db_handle;
> 
>  sqlite3_open(DB_NAME,_handle);
>  sqlite3_close(db_handle);
>  my_ping("10.0.0.4");
> 
>   return 0;
> }
> 
> If I call close after ping, it works. However, if besides of opening the DB
> I perform any query, ping doesnt work either.

My best guess is that you are making an error with file descriptors.  It
can be quite easy to accidentally use various values with low numbers
instead of the actual file descriptor numbers, and you'll get away with
it until some other code (eg sqlite) opens and closes files.  (Note that
under some circumstances SQLite can leave file descriptors open even
after close is called.)

I suggest using strace and carefully examining the file descriptors used.

Roger
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkupxGUACgkQmOOfHg372QTd2ACeNaCEFII4TuVK8ZtTpCvZeFeX
ivYAnjuLh8uKl1z1jVauy9Fxa60Po9RR
=AVyR
-END PGP SIGNATURE-
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQlite C API screwing port access?

[Simon Slavin]

On 23 Mar 2010, at 7:29pm, Martin Sigwald wrote:

> DB_NAME equals "servers.db".
> Both close and open return 0, my code catches a possible error, I didnt
> included for legibility.
> I tired using ":memory:", same result: cant ping.
> These is quite frustrating.

Hmm.  Thanks for trying.  If both of those fail, I haven't clue what's wrong.  
The _close routine is too complicated to let me strip it.  You need someone 
with a better knowledge of S3 than I have.  Sorry.

Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQlite C API screwing port access?

[Martin Sigwald]

DB_NAME equals "servers.db".
Both close and open return 0, my code catches a possible error, I didnt
included for legibility.
I tired using ":memory:", same result: cant ping.
These is quite frustrating.

On Tue, Mar 23, 2010 at 4:23 PM, Simon Slavin  wrote:

>
> On 23 Mar 2010, at 7:06pm, Martin Sigwald wrote:
>
> > Here is the actual code:
> >
> > int main(void)
> > {
> >sqlite3* db_handle;
> >
> > sqlite3_open(DB_NAME,_handle);
> > sqlite3_close(db_handle);
> > my_ping("10.0.0.4");
> >
> >  return 0;
> > }
> >
> > If I call close after ping, it works. However, if besides of opening the
> DB
> > I perform any query, ping doesnt work either.
>
> I suspect that your value for DB_NAME has some bad syntax in it which has a
> result only when you try to close the database.  Please tell us what values
> are returned by _open and _close.  The value returned should be an integer:
>
>  int rcOpen, rcClose;
>  rcOpen = sqlite3_open(DB_NAME,_handle);
>  // output the value of rcOpen here
>  rcClose = sqlite3_close(db_handle);
>  // output the value of rcClose here
>
> You can see possible result codes here: <
> http://www.sqlite.org/c3ref/c_abort.html>
>
> If both functions yield zero in your test, indicating all is fine, please
> try this new test code using ":memory:" where you currently have DB_NAME and
> see if your program still locks up.
>
> Simon.
> ___
> 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

Re: [sqlite] SQlite C API screwing port access?

[Simon Slavin]

On 23 Mar 2010, at 7:06pm, Martin Sigwald wrote:

> Here is the actual code:
> 
> int main(void)
> {
>sqlite3* db_handle;
> 
> sqlite3_open(DB_NAME,_handle);
> sqlite3_close(db_handle);
> my_ping("10.0.0.4");
> 
>  return 0;
> }
> 
> If I call close after ping, it works. However, if besides of opening the DB
> I perform any query, ping doesnt work either.

I suspect that your value for DB_NAME has some bad syntax in it which has a 
result only when you try to close the database.  Please tell us what values are 
returned by _open and _close.  The value returned should be an integer:

  int rcOpen, rcClose;
  rcOpen = sqlite3_open(DB_NAME,_handle);
  // output the value of rcOpen here
  rcClose = sqlite3_close(db_handle);
  // output the value of rcClose here

You can see possible result codes here: 


If both functions yield zero in your test, indicating all is fine, please try 
this new test code using ":memory:" where you currently have DB_NAME and see if 
your program still locks up.

Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQlite C API screwing port access?

[Martin Sigwald]

Here is the actual code:

int main(void)
{
sqlite3* db_handle;

 sqlite3_open(DB_NAME,_handle);
 sqlite3_close(db_handle);
 my_ping("10.0.0.4");

  return 0;
}

If I call close after ping, it works. However, if besides of opening the DB
I perform any query, ping doesnt work either.

On Tue, Mar 23, 2010 at 3:45 PM, Matthew L. Creech wrote:

> On Tue, Mar 23, 2010 at 12:55 PM, Martin Sigwald 
> wrote:
> > I have a program which builds an ICMP package over IP and sends it.
> Before
> > that, I get IP number and other information from a SQlite DB. I was
> having
> > problems, so I began to comment different parts of the code, until I got
> to
> > this code (pseudocode):
> >
> > sqlite3_open(DB_NAME);
> > sqlite3_close(DB_NAME);
> >
> > ping_server("10.0.0.4"); //my ping function, which pings a "hardcoded"
> IP,
> > doesnt interact with DB
> >
>
> Could you post the actual code snippet?  For example, sqlite3_close()
> doesn't take a string - you did say it's pseudocode, I'm just
> wondering if there's a problem with the arguments along those lines.
>
> --
> Matthew L. Creech
> ___
> 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

Re: [sqlite] SQlite C API screwing port access?

[Matthew L. Creech]

On Tue, Mar 23, 2010 at 12:55 PM, Martin Sigwald  wrote:
> I have a program which builds an ICMP package over IP and sends it. Before
> that, I get IP number and other information from a SQlite DB. I was having
> problems, so I began to comment different parts of the code, until I got to
> this code (pseudocode):
>
> sqlite3_open(DB_NAME);
> sqlite3_close(DB_NAME);
>
> ping_server("10.0.0.4"); //my ping function, which pings a "hardcoded" IP,
> doesnt interact with DB
>

Could you post the actual code snippet?  For example, sqlite3_close()
doesn't take a string - you did say it's pseudocode, I'm just
wondering if there's a problem with the arguments along those lines.

-- 
Matthew L. Creech
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQlite C API screwing port access?

[Pavel Ivanov]

> Pavel: Yes, I allocate memory inside the ping function, but that is done
> after calling de sqlite functions. There are no pointers shared between the
> sqlite functions and the ping part.

Actually I meant pointers shared between ping part and the part before
calls to sqlite functions.
Did you try running under valgrind?


Pavel

On Tue, Mar 23, 2010 at 2:10 PM, Martin Sigwald  wrote:
> I already tried that, and the first ping works while the second one doesn't,
> which validates my "screwing ports theory".
>
> Simon: Tried changing the DB_NAME and it didnt work either.
>
> Pavlov: Yes, I allocate memory inside the ping function, but that is done
> after calling de sqlite functions. There are no pointers shared between the
> sqlite functions and the ping part.
>
> On Tue, Mar 23, 2010 at 3:00 PM, Teg  wrote:
>
>> Hello Martin,
>>
>> Do the ping both before and after you open the DB.
>>
>> ping_server("10.0.0.4"); //my ping function, which pings a "hardcoded" IP,
>> sqlite3_open(DB_NAME);
>> sqlite3_close(DB_NAME);
>> ping_server("10.0.0.4"); //my ping function, which pings a "hardcoded" IP,
>>
>> See if the first one works. That'll validate your theory. My guess is
>> the first one won't work either and you're barking up the wrong tree.
>>
>> C
>>
>> Tuesday, March 23, 2010, 12:55:36 PM, you wrote:
>>
>> MS> I have a program which builds an ICMP package over IP and sends it.
>> Before
>> MS> that, I get IP number and other information from a SQlite DB. I was
>> having
>> MS> problems, so I began to comment different parts of the code, until I
>> got to
>> MS> this code (pseudocode):
>>
>> MS> sqlite3_open(DB_NAME);
>> MS> sqlite3_close(DB_NAME);
>>
>> MS> ping_server("10.0.0.4"); //my ping function, which pings a "hardcoded"
>> IP,
>> MS> doesnt interact with DB
>>
>>
>> MS> If I run that code, the package nevers gets send (can't detect it with
>> MS> Wireshark). If a comment the sqlite part, it works perfectly. Somehow,
>> the
>> MS> SQlite function calls are screwing with the port access, but I can't
>> fin any
>> MS> reasonable explanation.
>> MS> Any ideas?
>> MS> I've been stuck for days with this problem.
>>
>> MS> Regards,
>> MS> Martin Sigwald
>> MS> ___
>> MS> sqlite-users mailing list
>> MS> sqlite-users@sqlite.org
>> MS> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>>
>>
>>
>> --
>> Best regards,
>>  Teg                            mailto:t...@djii.com
>>
>> ___
>> 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
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQlite C API screwing port access?

[Martin Sigwald]

I already tried that, and the first ping works while the second one doesn't,
which validates my "screwing ports theory".

Simon: Tried changing the DB_NAME and it didnt work either.

Pavlov: Yes, I allocate memory inside the ping function, but that is done
after calling de sqlite functions. There are no pointers shared between the
sqlite functions and the ping part.

On Tue, Mar 23, 2010 at 3:00 PM, Teg  wrote:

> Hello Martin,
>
> Do the ping both before and after you open the DB.
>
> ping_server("10.0.0.4"); //my ping function, which pings a "hardcoded" IP,
> sqlite3_open(DB_NAME);
> sqlite3_close(DB_NAME);
> ping_server("10.0.0.4"); //my ping function, which pings a "hardcoded" IP,
>
> See if the first one works. That'll validate your theory. My guess is
> the first one won't work either and you're barking up the wrong tree.
>
> C
>
> Tuesday, March 23, 2010, 12:55:36 PM, you wrote:
>
> MS> I have a program which builds an ICMP package over IP and sends it.
> Before
> MS> that, I get IP number and other information from a SQlite DB. I was
> having
> MS> problems, so I began to comment different parts of the code, until I
> got to
> MS> this code (pseudocode):
>
> MS> sqlite3_open(DB_NAME);
> MS> sqlite3_close(DB_NAME);
>
> MS> ping_server("10.0.0.4"); //my ping function, which pings a "hardcoded"
> IP,
> MS> doesnt interact with DB
>
>
> MS> If I run that code, the package nevers gets send (can't detect it with
> MS> Wireshark). If a comment the sqlite part, it works perfectly. Somehow,
> the
> MS> SQlite function calls are screwing with the port access, but I can't
> fin any
> MS> reasonable explanation.
> MS> Any ideas?
> MS> I've been stuck for days with this problem.
>
> MS> Regards,
> MS> Martin Sigwald
> MS> ___
> MS> sqlite-users mailing list
> MS> sqlite-users@sqlite.org
> MS> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
>
>
> --
> Best regards,
>  Tegmailto:t...@djii.com
>
> ___
> 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

Re: [sqlite] SQlite C API screwing port access?

[Teg]

Hello Martin,

Do the ping both before and after you open the DB.

ping_server("10.0.0.4"); //my ping function, which pings a "hardcoded" IP,
sqlite3_open(DB_NAME);
sqlite3_close(DB_NAME);
ping_server("10.0.0.4"); //my ping function, which pings a "hardcoded" IP,

See if the first one works. That'll validate your theory. My guess is
the first one won't work either and you're barking up the wrong tree.

C

Tuesday, March 23, 2010, 12:55:36 PM, you wrote:

MS> I have a program which builds an ICMP package over IP and sends it. Before
MS> that, I get IP number and other information from a SQlite DB. I was having
MS> problems, so I began to comment different parts of the code, until I got to
MS> this code (pseudocode):

MS> sqlite3_open(DB_NAME);
MS> sqlite3_close(DB_NAME);

MS> ping_server("10.0.0.4"); //my ping function, which pings a "hardcoded" IP,
MS> doesnt interact with DB


MS> If I run that code, the package nevers gets send (can't detect it with
MS> Wireshark). If a comment the sqlite part, it works perfectly. Somehow, the
MS> SQlite function calls are screwing with the port access, but I can't fin any
MS> reasonable explanation.
MS> Any ideas?
MS> I've been stuck for days with this problem.

MS> Regards,
MS> Martin Sigwald
MS> ___
MS> sqlite-users mailing list
MS> sqlite-users@sqlite.org
MS> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users



-- 
Best regards,
 Tegmailto:t...@djii.com

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQlite C API screwing port access?

[Simon Slavin]

On 23 Mar 2010, at 4:55pm, Martin Sigwald wrote:

> sqlite3_open(DB_NAME);
> sqlite3_close(DB_NAME);
> 
> ping_server("10.0.0.4"); //my ping function, which pings a "hardcoded" IP,
> doesnt interact with DB
> 
> 
> If I run that code, the package nevers gets send (can't detect it with
> Wireshark). If a comment the sqlite part, it works perfectly. Somehow, the
> SQlite function calls are screwing with the port access, but I can't fin any
> reasonable explanation.

Fascinating.  Okay, first try changing the DB_NAME to something else.  If the 
original is a file on a network share, try a local file.  Or try a file in your 
home folder.  Or try a SQLite database in memory.

Another approach is to omit the _close.  Just for your test application.  Or 
put the _close after the ping_server.  I know it's bad programming but there's 
no actual code there anyway.  See if it's the _open or _close that's the 
problem.

If neither of these give you a clue to the problem you could possibly copy the 
sqlite3 functions from the source code and include them specifically into your 
source code.  Then start stripping the functions themselves down to the bare 
bones.

Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQlite C API screwing port access?

[Pavel Ivanov]

Does your pinging code involves some pointers to memory (strings or
any other stuff) that could be already released before SQLite code is
called? Try to run your program under valgrind and see whether it
gives any errors.

Pavel

On Tue, Mar 23, 2010 at 12:55 PM, Martin Sigwald  wrote:
> I have a program which builds an ICMP package over IP and sends it. Before
> that, I get IP number and other information from a SQlite DB. I was having
> problems, so I began to comment different parts of the code, until I got to
> this code (pseudocode):
>
> sqlite3_open(DB_NAME);
> sqlite3_close(DB_NAME);
>
> ping_server("10.0.0.4"); //my ping function, which pings a "hardcoded" IP,
> doesnt interact with DB
>
>
> If I run that code, the package nevers gets send (can't detect it with
> Wireshark). If a comment the sqlite part, it works perfectly. Somehow, the
> SQlite function calls are screwing with the port access, but I can't fin any
> reasonable explanation.
> Any ideas?
> I've been stuck for days with this problem.
>
> Regards,
> Martin Sigwald
> ___
> 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

[sqlite] SQlite C API screwing port access?

[Martin Sigwald]

I have a program which builds an ICMP package over IP and sends it. Before
that, I get IP number and other information from a SQlite DB. I was having
problems, so I began to comment different parts of the code, until I got to
this code (pseudocode):

sqlite3_open(DB_NAME);
sqlite3_close(DB_NAME);

ping_server("10.0.0.4"); //my ping function, which pings a "hardcoded" IP,
doesnt interact with DB


If I run that code, the package nevers gets send (can't detect it with
Wireshark). If a comment the sqlite part, it works perfectly. Somehow, the
SQlite function calls are screwing with the port access, but I can't fin any
reasonable explanation.
Any ideas?
I've been stuck for days with this problem.

Regards,
Martin Sigwald
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users