Menu
▾
▴
qstat-devx
|
From: Steven H. <ki...@mu...> - 2008-04-24 22:24:34
|
In order to facilitate the ability to fix a number of core issues
with how qstat deals with servers I've been forced to commit some
sweeping changes which change the return of deal_with_ and send_
functions to return int's.
This is stage 1 of a 2 stage update which will allow some of the
nasty memory issues in qstat's core code to be fixed.
Included in this change is a version bump to 2.12. Until the rest
of the changes are complete please treat this as BETA code due
to the significant changes needed.
Regards
Steve
================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.
In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to pos...@mu....
|
|
From: Steven H. <ki...@mu...> - 2008-04-25 01:59:29
|
Stage two of this work has now been committed this removes virtually
all calls to cleanup_qserver, keeping them only in the core logic.
These calls have been replaced by simple meaningful return values.
I've done just a few tests on TMF to confirm this refactor is having
the desired effects i.e. fixing the memory corruption issue caused
by the interaction of various functions with the cleanup code being
called mid stream hence invaliding the server pointer.
Treat this code as BETA / Work In Progress!
Any feedback welcomed.
Regards
Steve
================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.
In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to pos...@mu....
|
|
From: Steven H. <ki...@mu...> - 2008-04-25 18:05:46
|
I've now completed my initial set of tests and fixes for this update.
A number of other issues where trapped and fixed with the help of efence
including a major memory corruption issue affecting any server which swaps
its port.
Given this I'd encourage people to now test this latest version in their
environments to see if it uncovers any issues.
Regards
Steve
================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.
In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to pos...@mu....
|
|
From: Ludwig N. <l-...@us...> - 2008-04-25 22:20:52
|
Steven Hartland wrote: > A number of other issues where trapped and fixed with the help of efence > including a major memory corruption issue affecting any server which swaps > its port. Have you tried valgrind? It catches more than just malloc errors. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ PGP Key: FF8135CE |
|
From: Steven H. <ki...@mu...> - 2008-04-26 10:20:59
|
Looked at it but wouldn't compile here saying it only runs on i386 even though
their docs claim amd64 compat.
Regards
Steve
----- Original Message -----
From: "Ludwig Nussel" <l-...@us...>
To: <qst...@li...>
Sent: Friday, April 25, 2008 11:20 PM
Subject: Re: [QStat-devx] HEADSUP: deal_with_ and send_ now return int's
> Steven Hartland wrote:
>> A number of other issues where trapped and fixed with the help of efence
>> including a major memory corruption issue affecting any server which swaps
>> its port.
>
> Have you tried valgrind? It catches more than just malloc errors.
================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.
In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to pos...@mu....
|
|
From: Ludwig N. <l-...@us...> - 2008-04-26 17:56:30
|
Steven Hartland wrote: > Looked at it but wouldn't compile here saying it only runs on i386 > even though their docs claim amd64 compat. Works on x86_64 for sure. I just use the distro package though. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ PGP Key: FF8135CE |
|
From: Steven H. <ki...@mu...> - 2008-04-26 18:10:10
|
x86_64 sounds like a Linux distro not BSD? ----- Original Message ----- From: "Ludwig Nussel" <l-...@us...> > Steven Hartland wrote: >> Looked at it but wouldn't compile here saying it only runs on i386 >> even though their docs claim amd64 compat. > > Works on x86_64 for sure. I just use the distro package though. ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to pos...@mu.... |
|
From: Pierre S. <pi...@un...> - 2008-04-26 21:23:06
|
Steve, I'm still having those issues on my freebsd 7 64bit box. I'm going to try a clean install in vmware and see what happens there. Pierre Steven Hartland wrote: > x86_64 sounds like a Linux distro not BSD? > > ----- Original Message ----- > From: "Ludwig Nussel" <l-...@us...> > > > >> Steven Hartland wrote: >> >>> Looked at it but wouldn't compile here saying it only runs on i386 >>> even though their docs claim amd64 compat. >>> >> Works on x86_64 for sure. I just use the distro package though. >> > > > ================================================ > This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. > > In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 > or return the E.mail to pos...@mu.... > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > QStat-devx mailing list > QSt...@li... > https://lists.sourceforge.net/lists/listinfo/qstat-devx > |
|
From: Ludwig N. <l-...@us...> - 2008-04-25 21:05:55
|
Steven Hartland wrote: > Included in this change is a version bump to 2.12. Until the rest > of the changes are complete please treat this as BETA code due > to the significant changes needed. It's always beta as long as it's in svn. Sometimes more and sometimes less. The version number is basically meaningless. However there should be no 2.12 before 2.12 is actually released. Otherwise packagers that package svn snapshots might fall into the trap that the final version suddenly has the same or even a lower version than the snapshots. So I'd rather use something like 2.11.1, 2.11.2 etc for bigger changes in svn and only bump the version to 2.12 immediately before the release. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ PGP Key: FF8135CE |
|
From: Pierre S. <pi...@un...> - 2008-09-09 21:04:46
|
Hello All, Due to some incompatibility issues with other licenses, I've been advised, and agree, that we should move to Artistic 2.0. I've received approval/direction from Steve J. already and as we're under a time constraint to make this change over the next couple days (see below) I plan to update qstat on SVN later tonight and bundle a release for some linux distros. > Currently, Fedora is including qstat, which is licensed under > the Artistic 1.0 license. This license is no longer a permitted > license in > Fedora. > > Why? > > 1. The FSF says it isn't free. They say that the text is vague, > and > that it is open to misinterpretation. > 2. The perl community (the original authors) agrees with this > assessment. They went so far as to rewrite the Artistic > license > to resolve all the identified problems (see > http://www.perlfoundation.org/artistic_license_2_0). > 3. The OSI has "superseded" the license, recommending strongly > that > all users move to Artistic 2.0: > http://opensource.org/licenses/artistic-license-1.0.php > > qstat is a useful package, which a fair amount of other Fedora > packages depend upon, so we would really prefer not to remove it. Is > there any chance you would consider relicensing this code, for > example, > under the same license as perl5 (GPL+ or Artistic)? > > Please get back to me ASAP, our window is almost gone to keep this > code > in Fedora. I apologize for the short notice and I appreciate your patience with me. Hopefully there is no unforeseen issue with this, so please let me know otherwise. I plan to let the users group know about this change later on in the week - just wanted you guys to know first. Regards Pierre. |
|
From: Steven H. <ki...@mu...> - 2008-09-10 08:15:56
|
Should we not consider moving to something like BSD license?
Regards
Steve
----- Original Message -----
From: "Pierre Smolarek" <pi...@un...>
To: <qst...@li...>
Sent: Tuesday, September 09, 2008 10:05 PM
Subject: [QStat-devx] License of Qstat Changing to Artistic 2.0
> Hello All,
>
> Due to some incompatibility issues with other licenses, I've been
> advised, and agree, that we should move to Artistic 2.0. I've received
> approval/direction from Steve J. already and as we're under a time
> constraint to make this change over the next couple days (see below) I
> plan to update qstat on SVN later tonight and bundle a release for some
> linux distros.
>
>> Currently, Fedora is including qstat, which is licensed under
>> the Artistic 1.0 license. This license is no longer a permitted
>> license in
>> Fedora.
>>
>> Why?
>>
>> 1. The FSF says it isn't free. They say that the text is vague,
>> and
>> that it is open to misinterpretation.
>> 2. The perl community (the original authors) agrees with this
>> assessment. They went so far as to rewrite the Artistic
>> license
>> to resolve all the identified problems (see
>> http://www.perlfoundation.org/artistic_license_2_0).
>> 3. The OSI has "superseded" the license, recommending strongly
>> that
>> all users move to Artistic 2.0:
>> http://opensource.org/licenses/artistic-license-1.0.php
>>
>> qstat is a useful package, which a fair amount of other Fedora
>> packages depend upon, so we would really prefer not to remove it. Is
>> there any chance you would consider relicensing this code, for
>> example,
>> under the same license as perl5 (GPL+ or Artistic)?
>>
>> Please get back to me ASAP, our window is almost gone to keep this
>> code
>> in Fedora.
>
>
>
> I apologize for the short notice and I appreciate your patience with me.
> Hopefully there is no unforeseen issue with this, so please let me know
> otherwise.
>
> I plan to let the users group know about this change later on in the
> week - just wanted you guys to know first.
>
> Regards
>
> Pierre.
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> QStat-devx mailing list
> QSt...@li...
> https://lists.sourceforge.net/lists/listinfo/qstat-devx
>
================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.
In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to pos...@mu....
|
|
From: Ludwig N. <l-...@us...> - 2008-09-10 17:59:28
|
Steven Hartland wrote: > Should we not consider moving to something like BSD license? That would mean anyone could turn qstat into something proprietary. Artistic License 2 is fine for me. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ PGP Key: FF8135CE |
|
From: Pierre S. <pi...@un...> - 2009-08-13 14:15:58
|
Hello,
Been a while since I posted a qstat bug but here's one for you both.
debug(2) 22:21:07 qstat.c:3092 do_work() - connected, pre-packet_func: 129
debug(3) 22:21:07 a2s.c:165 deal_with_a2s_packet() - sequenceId: 31229
debug(3) 22:21:07 a2s.c:190 deal_with_a2s_packet() - packetid[2]: 0x2 =>
idx: 255, max: 2
debug(4) 22:21:07 packet_manip.c:42 combine_packets() - max:2, id:31229
*Too many fragments 255 for packetid 31229 max 16*
debug(3) 22:21:07 qstat.c:4722 process_func_ret() - 0x201544c40, 0
debug(2) 22:21:07 qstat.c:3094 do_work() - connected, post-packet_func: 129
FROM 62.231.190.35:27017 len 243
0: ffffffff 4408004d 75733163 2e736861 ....D..M us1c.sha
16: 67756172 00010000 0000d014 42005b50 guar.... ....B.[P
32: 4f445d43 6861726c 69655f53 6865656e OD]Charl ie_Sheen
48: 20283936 29002200 00002ad9 6b48005b (96).". ..*.kH.[
64: 504f445d 5765736c 65795f53 6e697065 POD]Wesl ey_Snipe
80: 73202831 30302900 14000000 2ad96b48 s (100). ....*.kH
96: 005b504f 445d4368 65656368 204d6172 .[POD]Ch eech Mar
112: 696e2028 39352900 11000000 2ad96b48 in (95). ....*.kH
128: 005b5030 445d4368 7269735f 526f636b .[P0D]Ch ris_Rock
144: 20283939 29000e00 00002ad9 6b48005b (99)... ..*.kH.[
160: 504f445d 526f6265 72745f44 6f776e65 POD]Robe rt_Downe
176: 795f4a72 20283937 29001500 00002ad9 y_Jr (97 ).....*.
192: 6b48005b 5030445d 44616e6e 795f4465 kH.[P0D] Danny_De
208: 7669746f 20283936 29000e00 00002ad9 vito (96 ).....*.
224: 6b480052 49434841 5244000e 00000000 kH.RICHA RD......
240: a6d343 ..C
and
debug(2) 22:21:07 qstat.c:3092 do_work() - connected, pre-packet_func: 128
debug(3) 22:21:07 a2s.c:165 deal_with_a2s_packet() - sequenceId: 31229
debug(3) 22:21:07 a2s.c:190 deal_with_a2s_packet() - packetid[2]: 0x12
=> idx: 0, max: 18
debug(4) 22:21:07 packet_manip.c:42 combine_packets() - max:2, id:31229
*Too many fragments 255 for packetid 31229 max 16
*debug(4) 22:21:07 packet_manip.c:42 combine_packets() - max:18, id:31229
debug(4) 22:21:07 packet_manip.c:106 combine_packets() - more expected:
1 != 18
debug(3) 22:21:07 qstat.c:4722 process_func_ret() - 0x201544c40, 0
debug(2) 22:21:07 qstat.c:3094 do_work() - connected, post-packet_func: 128
FROM 62.231.190.39:27015 len 30
0: ffffffff 4401005b 20484c54 56205072 ....D..[ HLTV Pr
16: 6f787920 5d000000 0000926e 2247 oxy ]... ...n"G
Let me know what you think.
Thanks,
Pierre
|
|
From: Steven H. <ki...@mu...> - 2009-08-13 15:32:12
|
Questions:
1. Command line used?
2. Game?
3. qstat version?
Regards
Steve
----- Original Message -----
From: Pierre Smolarek
To: qst...@li...
Sent: Thursday, August 13, 2009 2:56 PM
Subject: [QStat-devx] Qstat A2S causing "Too many fragments" error
Hello,
Been a while since I posted a qstat bug but here's one for you both.
debug(2) 22:21:07 qstat.c:3092 do_work() - connected, pre-packet_func: 129
debug(3) 22:21:07 a2s.c:165 deal_with_a2s_packet() - sequenceId: 31229
debug(3) 22:21:07 a2s.c:190 deal_with_a2s_packet() - packetid[2]: 0x2 => idx: 255, max: 2
debug(4) 22:21:07 packet_manip.c:42 combine_packets() - max:2, id:31229
Too many fragments 255 for packetid 31229 max 16
debug(3) 22:21:07 qstat.c:4722 process_func_ret() - 0x201544c40, 0
debug(2) 22:21:07 qstat.c:3094 do_work() - connected, post-packet_func: 129
FROM 62.231.190.35:27017 len 243
0: ffffffff 4408004d 75733163 2e736861 ....D..M us1c.sha
16: 67756172 00010000 0000d014 42005b50 guar.... ....B.[P
32: 4f445d43 6861726c 69655f53 6865656e OD]Charl ie_Sheen
48: 20283936 29002200 00002ad9 6b48005b (96).". ..*.kH.[
64: 504f445d 5765736c 65795f53 6e697065 POD]Wesl ey_Snipe
80: 73202831 30302900 14000000 2ad96b48 s (100). ....*.kH
96: 005b504f 445d4368 65656368 204d6172 .[POD]Ch eech Mar
112: 696e2028 39352900 11000000 2ad96b48 in (95). ....*.kH
128: 005b5030 445d4368 7269735f 526f636b .[P0D]Ch ris_Rock
144: 20283939 29000e00 00002ad9 6b48005b (99)... ..*.kH.[
160: 504f445d 526f6265 72745f44 6f776e65 POD]Robe rt_Downe
176: 795f4a72 20283937 29001500 00002ad9 y_Jr (97 ).....*.
192: 6b48005b 5030445d 44616e6e 795f4465 kH.[P0D] Danny_De
208: 7669746f 20283936 29000e00 00002ad9 vito (96 ).....*.
224: 6b480052 49434841 5244000e 00000000 kH.RICHA RD......
240: a6d343 ..C
and
debug(2) 22:21:07 qstat.c:3092 do_work() - connected, pre-packet_func: 128
debug(3) 22:21:07 a2s.c:165 deal_with_a2s_packet() - sequenceId: 31229
debug(3) 22:21:07 a2s.c:190 deal_with_a2s_packet() - packetid[2]: 0x12 => idx: 0, max: 18
debug(4) 22:21:07 packet_manip.c:42 combine_packets() - max:2, id:31229
Too many fragments 255 for packetid 31229 max 16
debug(4) 22:21:07 packet_manip.c:42 combine_packets() - max:18, id:31229
debug(4) 22:21:07 packet_manip.c:106 combine_packets() - more expected: 1 != 18
debug(3) 22:21:07 qstat.c:4722 process_func_ret() - 0x201544c40, 0
debug(2) 22:21:07 qstat.c:3094 do_work() - connected, post-packet_func: 128
FROM 62.231.190.39:27015 len 30
0: ffffffff 4401005b 20484c54 56205072 ....D..[ HLTV Pr
16: 6f787920 5d000000 0000926e 2247 oxy ]... ...n"G
Let me know what you think.
Thanks,
Pierre
------------------------------------------------------------------------------
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
------------------------------------------------------------------------------
_______________________________________________
QStat-devx mailing list
QSt...@li...
https://lists.sourceforge.net/lists/listinfo/qstat-devx
================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.
In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to pos...@mu.... |
|
From: Pierre S. <pi...@un...> - 2009-08-14 14:08:12
|
Hello Steven /qstat/qstat -d -d -d -d -R -P -a2s 62.231.190.35:27017 cssource (a2s) latest subversion version when i use that command above it will just loop the query forever. I'm seeing several servers do this. 62.231.190.35:27017 css 62.231.190.39:27015 css (hltv) 62.181.0.142:27213 62.181.0.138:27081 67.93.155.120:27014 62.168.75.69:27017 FreeBSD 7.0-RELEASE-p1 Pierre Steven Hartland wrote: > Questions: > 1. Command line used? > 2. Game? > 3. qstat version? > > Regards > Steve > > ----- Original Message ----- > *From:* Pierre Smolarek <mailto:pi...@un...> > *To:* qst...@li... > <mailto:qst...@li...> > *Sent:* Thursday, August 13, 2009 2:56 PM > *Subject:* [QStat-devx] Qstat A2S causing "Too many fragments" error > > Hello, > > Been a while since I posted a qstat bug but here's one for you both. > > debug(2) 22:21:07 qstat.c:3092 do_work() - connected, > pre-packet_func: 129 > debug(3) 22:21:07 a2s.c:165 deal_with_a2s_packet() - sequenceId: 31229 > debug(3) 22:21:07 a2s.c:190 deal_with_a2s_packet() - packetid[2]: > 0x2 => idx: 255, max: 2 > debug(4) 22:21:07 packet_manip.c:42 combine_packets() - max:2, > id:31229 > *Too many fragments 255 for packetid 31229 max 16* > debug(3) 22:21:07 qstat.c:4722 process_func_ret() - 0x201544c40, 0 > debug(2) 22:21:07 qstat.c:3094 do_work() - connected, > post-packet_func: 129 > FROM 62.231.190.35:27017 len 243 > 0: ffffffff 4408004d 75733163 2e736861 ....D..M us1c.sha > 16: 67756172 00010000 0000d014 42005b50 guar.... ....B.[P > 32: 4f445d43 6861726c 69655f53 6865656e OD]Charl ie_Sheen > 48: 20283936 29002200 00002ad9 6b48005b (96).". ..*.kH.[ > 64: 504f445d 5765736c 65795f53 6e697065 POD]Wesl ey_Snipe > 80: 73202831 30302900 14000000 2ad96b48 s (100). ....*.kH > 96: 005b504f 445d4368 65656368 204d6172 .[POD]Ch eech Mar > 112: 696e2028 39352900 11000000 2ad96b48 in (95). ....*.kH > 128: 005b5030 445d4368 7269735f 526f636b .[P0D]Ch ris_Rock > 144: 20283939 29000e00 00002ad9 6b48005b (99)... ..*.kH.[ > 160: 504f445d 526f6265 72745f44 6f776e65 POD]Robe rt_Downe > 176: 795f4a72 20283937 29001500 00002ad9 y_Jr (97 ).....*. > 192: 6b48005b 5030445d 44616e6e 795f4465 kH.[P0D] Danny_De > 208: 7669746f 20283936 29000e00 00002ad9 vito (96 ).....*. > 224: 6b480052 49434841 5244000e 00000000 kH.RICHA RD...... > 240: a6d343 ..C > > > and > > > debug(2) 22:21:07 qstat.c:3092 do_work() - connected, > pre-packet_func: 128 > debug(3) 22:21:07 a2s.c:165 deal_with_a2s_packet() - sequenceId: 31229 > debug(3) 22:21:07 a2s.c:190 deal_with_a2s_packet() - packetid[2]: > 0x12 => idx: 0, max: 18 > debug(4) 22:21:07 packet_manip.c:42 combine_packets() - max:2, > id:31229 > *Too many fragments 255 for packetid 31229 max 16 > *debug(4) 22:21:07 packet_manip.c:42 combine_packets() - max:18, > id:31229 > debug(4) 22:21:07 packet_manip.c:106 combine_packets() - more > expected: 1 != 18 > debug(3) 22:21:07 qstat.c:4722 process_func_ret() - 0x201544c40, 0 > debug(2) 22:21:07 qstat.c:3094 do_work() - connected, > post-packet_func: 128 > FROM 62.231.190.39:27015 len 30 > 0: ffffffff 4401005b 20484c54 56205072 ....D..[ HLTV Pr > 16: 6f787920 5d000000 0000926e 2247 oxy ]... ...n"G > > > > Let me know what you think. > > > Thanks, > > Pierre > > > ------------------------------------------------------------------------ > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports > 2008 30-Day > trial. Simplify your report design, integration and deployment - > and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > > ------------------------------------------------------------------------ > _______________________________________________ > QStat-devx mailing list > QSt...@li... > https://lists.sourceforge.net/lists/listinfo/qstat-devx > > > ================================================ > This e.mail is private and confidential between Multiplay (UK) Ltd. > and the person or entity to whom it is addressed. In the event of > misdirection, the recipient is prohibited from using, copying, > printing or otherwise disseminating it or any information contained in > it. > > In the event of misdirection, illegible or incomplete transmission > please telephone +44 845 868 1337 > or return the E.mail to pos...@mu.... > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > ------------------------------------------------------------------------ > > _______________________________________________ > QStat-devx mailing list > QSt...@li... > https://lists.sourceforge.net/lists/listinfo/qstat-devx > |
|
From: Steven H. <ki...@mu...> - 2009-08-14 14:47:46
|
Looks like this is a very old server which isn't using
the new broken protocol which qstat is expecting. Try
updating the server.
Regards
Steve
----- Original Message -----
From: "Pierre Smolarek" <pi...@un...>
To: "Steven Hartland" <ki...@mu...>
Cc: <qst...@li...>
Sent: Friday, August 14, 2009 3:07 PM
Subject: Re: [QStat-devx] Qstat A2S causing "Too many fragments" error
> Hello Steven
>
> /qstat/qstat -d -d -d -d -R -P -a2s 62.231.190.35:27017
>
> cssource (a2s)
>
> latest subversion version
>
> when i use that command above it will just loop the query forever. I'm
> seeing several servers do this.
>
> 62.231.190.35:27017 css
> 62.231.190.39:27015 css (hltv)
> 62.181.0.142:27213
> 62.181.0.138:27081
> 67.93.155.120:27014
> 62.168.75.69:27017
>
> FreeBSD 7.0-RELEASE-p1
>
>
>
> Pierre
>
>
> Steven Hartland wrote:
>> Questions:
>> 1. Command line used?
>> 2. Game?
>> 3. qstat version?
>>
>> Regards
>> Steve
>>
>> ----- Original Message -----
>> *From:* Pierre Smolarek <mailto:pi...@un...>
>> *To:* qst...@li...
>> <mailto:qst...@li...>
>> *Sent:* Thursday, August 13, 2009 2:56 PM
>> *Subject:* [QStat-devx] Qstat A2S causing "Too many fragments" error
>>
>> Hello,
>>
>> Been a while since I posted a qstat bug but here's one for you both.
>>
>> debug(2) 22:21:07 qstat.c:3092 do_work() - connected,
>> pre-packet_func: 129
>> debug(3) 22:21:07 a2s.c:165 deal_with_a2s_packet() - sequenceId: 31229
>> debug(3) 22:21:07 a2s.c:190 deal_with_a2s_packet() - packetid[2]:
>> 0x2 => idx: 255, max: 2
>> debug(4) 22:21:07 packet_manip.c:42 combine_packets() - max:2,
>> id:31229
>> *Too many fragments 255 for packetid 31229 max 16*
>> debug(3) 22:21:07 qstat.c:4722 process_func_ret() - 0x201544c40, 0
>> debug(2) 22:21:07 qstat.c:3094 do_work() - connected,
>> post-packet_func: 129
>> FROM 62.231.190.35:27017 len 243
>> 0: ffffffff 4408004d 75733163 2e736861 ....D..M us1c.sha
>> 16: 67756172 00010000 0000d014 42005b50 guar.... ....B.[P
>> 32: 4f445d43 6861726c 69655f53 6865656e OD]Charl ie_Sheen
>> 48: 20283936 29002200 00002ad9 6b48005b (96).". ..*.kH.[
>> 64: 504f445d 5765736c 65795f53 6e697065 POD]Wesl ey_Snipe
>> 80: 73202831 30302900 14000000 2ad96b48 s (100). ....*.kH
>> 96: 005b504f 445d4368 65656368 204d6172 .[POD]Ch eech Mar
>> 112: 696e2028 39352900 11000000 2ad96b48 in (95). ....*.kH
>> 128: 005b5030 445d4368 7269735f 526f636b .[P0D]Ch ris_Rock
>> 144: 20283939 29000e00 00002ad9 6b48005b (99)... ..*.kH.[
>> 160: 504f445d 526f6265 72745f44 6f776e65 POD]Robe rt_Downe
>> 176: 795f4a72 20283937 29001500 00002ad9 y_Jr (97 ).....*.
>> 192: 6b48005b 5030445d 44616e6e 795f4465 kH.[P0D] Danny_De
>> 208: 7669746f 20283936 29000e00 00002ad9 vito (96 ).....*.
>> 224: 6b480052 49434841 5244000e 00000000 kH.RICHA RD......
>> 240: a6d343 ..C
>>
>>
>> and
>>
>>
>> debug(2) 22:21:07 qstat.c:3092 do_work() - connected,
>> pre-packet_func: 128
>> debug(3) 22:21:07 a2s.c:165 deal_with_a2s_packet() - sequenceId: 31229
>> debug(3) 22:21:07 a2s.c:190 deal_with_a2s_packet() - packetid[2]:
>> 0x12 => idx: 0, max: 18
>> debug(4) 22:21:07 packet_manip.c:42 combine_packets() - max:2,
>> id:31229
>> *Too many fragments 255 for packetid 31229 max 16
>> *debug(4) 22:21:07 packet_manip.c:42 combine_packets() - max:18,
>> id:31229
>> debug(4) 22:21:07 packet_manip.c:106 combine_packets() - more
>> expected: 1 != 18
>> debug(3) 22:21:07 qstat.c:4722 process_func_ret() - 0x201544c40, 0
>> debug(2) 22:21:07 qstat.c:3094 do_work() - connected,
>> post-packet_func: 128
>> FROM 62.231.190.39:27015 len 30
>> 0: ffffffff 4401005b 20484c54 56205072 ....D..[ HLTV Pr
>> 16: 6f787920 5d000000 0000926e 2247 oxy ]... ...n"G
>>
>>
>>
>> Let me know what you think.
>>
>>
>> Thanks,
>>
>> Pierre
>>
>>
>> ------------------------------------------------------------------------
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports
>> 2008 30-Day
>> trial. Simplify your report design, integration and deployment -
>> and focus on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>>
>> ------------------------------------------------------------------------
>> _______________________________________________
>> QStat-devx mailing list
>> QSt...@li...
>> https://lists.sourceforge.net/lists/listinfo/qstat-devx
>>
>>
>> ================================================
>> This e.mail is private and confidential between Multiplay (UK) Ltd.
>> and the person or entity to whom it is addressed. In the event of
>> misdirection, the recipient is prohibited from using, copying,
>> printing or otherwise disseminating it or any information contained in
>> it.
>>
>> In the event of misdirection, illegible or incomplete transmission
>> please telephone +44 845 868 1337
>> or return the E.mail to pos...@mu....
>> ------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>> trial. Simplify your report design, integration and deployment - and focus on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> QStat-devx mailing list
>> QSt...@li...
>> https://lists.sourceforge.net/lists/listinfo/qstat-devx
>>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> QStat-devx mailing list
> QSt...@li...
> https://lists.sourceforge.net/lists/listinfo/qstat-devx
>
================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.
In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to pos...@mu....
|
|
From: Pierre S. <pi...@un...> - 2009-08-14 15:37:07
|
Steve, Would love to update the server but as you may remember, serverspy.net just scans all servers on the master lists so thats not possible. Is there any way to just reject the server in qstat and return no data? Pierre Steven Hartland wrote: > Looks like this is a very old server which isn't using > the new broken protocol which qstat is expecting. Try > updating the server. > > Regards > Steve > > ----- Original Message ----- From: "Pierre Smolarek" > <pi...@un...> > To: "Steven Hartland" <ki...@mu...> > Cc: <qst...@li...> > Sent: Friday, August 14, 2009 3:07 PM > Subject: Re: [QStat-devx] Qstat A2S causing "Too many fragments" error > > >> Hello Steven >> >> /qstat/qstat -d -d -d -d -R -P -a2s 62.231.190.35:27017 >> >> cssource (a2s) >> >> latest subversion version >> >> when i use that command above it will just loop the query forever. I'm >> seeing several servers do this. >> >> 62.231.190.35:27017 css >> 62.231.190.39:27015 css (hltv) >> 62.181.0.142:27213 >> 62.181.0.138:27081 >> 67.93.155.120:27014 >> 62.168.75.69:27017 >> >> FreeBSD 7.0-RELEASE-p1 >> >> >> >> Pierre >> >> >> Steven Hartland wrote: >>> Questions: >>> 1. Command line used? >>> 2. Game? >>> 3. qstat version? >>> >>> Regards >>> Steve >>> >>> ----- Original Message ----- >>> *From:* Pierre Smolarek <mailto:pi...@un...> >>> *To:* qst...@li... >>> <mailto:qst...@li...> >>> *Sent:* Thursday, August 13, 2009 2:56 PM >>> *Subject:* [QStat-devx] Qstat A2S causing "Too many fragments" >>> error >>> >>> Hello, >>> >>> Been a while since I posted a qstat bug but here's one for you >>> both. >>> >>> debug(2) 22:21:07 qstat.c:3092 do_work() - connected, >>> pre-packet_func: 129 >>> debug(3) 22:21:07 a2s.c:165 deal_with_a2s_packet() - sequenceId: >>> 31229 >>> debug(3) 22:21:07 a2s.c:190 deal_with_a2s_packet() - packetid[2]: >>> 0x2 => idx: 255, max: 2 >>> debug(4) 22:21:07 packet_manip.c:42 combine_packets() - max:2, >>> id:31229 >>> *Too many fragments 255 for packetid 31229 max 16* >>> debug(3) 22:21:07 qstat.c:4722 process_func_ret() - 0x201544c40, 0 >>> debug(2) 22:21:07 qstat.c:3094 do_work() - connected, >>> post-packet_func: 129 >>> FROM 62.231.190.35:27017 len 243 >>> 0: ffffffff 4408004d 75733163 2e736861 ....D..M us1c.sha >>> 16: 67756172 00010000 0000d014 42005b50 guar.... ....B.[P >>> 32: 4f445d43 6861726c 69655f53 6865656e OD]Charl ie_Sheen >>> 48: 20283936 29002200 00002ad9 6b48005b (96).". ..*.kH.[ >>> 64: 504f445d 5765736c 65795f53 6e697065 POD]Wesl ey_Snipe >>> 80: 73202831 30302900 14000000 2ad96b48 s (100). ....*.kH >>> 96: 005b504f 445d4368 65656368 204d6172 .[POD]Ch eech Mar >>> 112: 696e2028 39352900 11000000 2ad96b48 in (95). ....*.kH >>> 128: 005b5030 445d4368 7269735f 526f636b .[P0D]Ch ris_Rock >>> 144: 20283939 29000e00 00002ad9 6b48005b (99)... ..*.kH.[ >>> 160: 504f445d 526f6265 72745f44 6f776e65 POD]Robe rt_Downe >>> 176: 795f4a72 20283937 29001500 00002ad9 y_Jr (97 ).....*. >>> 192: 6b48005b 5030445d 44616e6e 795f4465 kH.[P0D] Danny_De >>> 208: 7669746f 20283936 29000e00 00002ad9 vito (96 ).....*. >>> 224: 6b480052 49434841 5244000e 00000000 kH.RICHA RD...... >>> 240: a6d343 ..C >>> >>> >>> and >>> >>> >>> debug(2) 22:21:07 qstat.c:3092 do_work() - connected, >>> pre-packet_func: 128 >>> debug(3) 22:21:07 a2s.c:165 deal_with_a2s_packet() - sequenceId: >>> 31229 >>> debug(3) 22:21:07 a2s.c:190 deal_with_a2s_packet() - packetid[2]: >>> 0x12 => idx: 0, max: 18 >>> debug(4) 22:21:07 packet_manip.c:42 combine_packets() - max:2, >>> id:31229 >>> *Too many fragments 255 for packetid 31229 max 16 >>> *debug(4) 22:21:07 packet_manip.c:42 combine_packets() - max:18, >>> id:31229 >>> debug(4) 22:21:07 packet_manip.c:106 combine_packets() - more >>> expected: 1 != 18 >>> debug(3) 22:21:07 qstat.c:4722 process_func_ret() - 0x201544c40, 0 >>> debug(2) 22:21:07 qstat.c:3094 do_work() - connected, >>> post-packet_func: 128 >>> FROM 62.231.190.39:27015 len 30 >>> 0: ffffffff 4401005b 20484c54 56205072 ....D..[ HLTV Pr >>> 16: 6f787920 5d000000 0000926e 2247 oxy ]... ...n"G >>> >>> >>> >>> Let me know what you think. >>> >>> >>> Thanks, >>> >>> Pierre >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> Let Crystal Reports handle the reporting - Free Crystal Reports >>> 2008 30-Day >>> trial. Simplify your report design, integration and deployment - >>> and focus on >>> what you do best, core application coding. Discover what's new with >>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> QStat-devx mailing list >>> QSt...@li... >>> https://lists.sourceforge.net/lists/listinfo/qstat-devx >>> >>> >>> ================================================ >>> This e.mail is private and confidential between Multiplay (UK) Ltd. >>> and the person or entity to whom it is addressed. In the event of >>> misdirection, the recipient is prohibited from using, copying, >>> printing or otherwise disseminating it or any information contained in >>> it. >>> >>> In the event of misdirection, illegible or incomplete transmission >>> please telephone +44 845 868 1337 >>> or return the E.mail to pos...@mu.... >>> ------------------------------------------------------------------------ >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>> 30-Day trial. Simplify your report design, integration and >>> deployment - and focus on what you do best, core application coding. >>> Discover what's new with Crystal Reports now. >>> http://p.sf.net/sfu/bobj-july >>> ------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> QStat-devx mailing list >>> QSt...@li... >>> https://lists.sourceforge.net/lists/listinfo/qstat-devx >>> >> >> >> ------------------------------------------------------------------------------ >> >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >> 30-Day trial. Simplify your report design, integration and deployment >> - and focus on what you do best, core application coding. Discover >> what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> QStat-devx mailing list >> QSt...@li... >> https://lists.sourceforge.net/lists/listinfo/qstat-devx >> > > ================================================ > This e.mail is private and confidential between Multiplay (UK) Ltd. > and the person or entity to whom it is addressed. In the event of > misdirection, the recipient is prohibited from using, copying, > printing or otherwise disseminating it or any information contained in > it. > In the event of misdirection, illegible or incomplete transmission > please telephone +44 845 868 1337 > or return the E.mail to pos...@mu.... > |
|
From: Steven H. <ki...@mu...> - 2008-04-25 21:24:49
|
I was never intending to release 2.12. Instead I'd suggest we moved to
2.13 once all the niggles are worked out and do a bin release then.
Regards
Steve
----- Original Message -----
From: "Ludwig Nussel" <l-...@us...>
To: <qst...@li...>
Sent: Friday, April 25, 2008 10:05 PM
Subject: Re: [QStat-devx] HEADSUP: deal_with_ and send_ now return int's
> Steven Hartland wrote:
>> Included in this change is a version bump to 2.12. Until the rest
>> of the changes are complete please treat this as BETA code due
>> to the significant changes needed.
>
> It's always beta as long as it's in svn. Sometimes more and
> sometimes less. The version number is basically meaningless. However
> there should be no 2.12 before 2.12 is actually released. Otherwise
> packagers that package svn snapshots might fall into the trap that
> the final version suddenly has the same or even a lower version than
> the snapshots. So I'd rather use something like 2.11.1, 2.11.2 etc
> for bigger changes in svn and only bump the version to 2.12
> immediately before the release.
================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.
In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to pos...@mu....
|
|
From: Pierre S. <pi...@un...> - 2008-04-25 22:30:03
|
Ludwig, i forgot to reply to all but i just suggested the following for version control: "We could follow a similar version numbering as perl, Where odd numbers are 'beta build' releases and even numbers are 'stable' releases? So, qstat 2.14.x would be considered stable, Qstat 2.13.x would be considered 'beta' ? " Steve H seemed to agree, so unless you have any complaints, I'd like to enact the above version numbering from now on. Pierre Ludwig Nussel wrote: > Steven Hartland wrote: > >> A number of other issues where trapped and fixed with the help of efence >> including a major memory corruption issue affecting any server which swaps >> its port. >> > > Have you tried valgrind? It catches more than just malloc errors. > > cu > Ludwig > > |
|
From: Ludwig N. <l-...@us...> - 2008-04-25 22:40:13
|
Pierre Smolarek wrote: > Ludwig, i forgot to reply to all but i just suggested the following for > version control: > > "We could follow a similar version numbering as perl, Where odd numbers > are 'beta build' releases and even numbers are 'stable' releases? > > So, qstat 2.14.x would be considered stable, Qstat 2.13.x would be > considered 'beta' ? " Nah, total overkill. Let's just continue with the current scheme which increments the second number with every release. If you desperately want to express bigger changes in svn with version numbers I'd suggest to use the third number for that purpose only and never use the third number in releases. I btw already have test qstat builds of svn snapshots in the opensuse build service[1]. I'll update them to current trunk tomorrow. cu Ludwig [1] http://software.opensuse.org/search -- (o_ Ludwig Nussel //\ V_/_ PGP Key: FF8135CE |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X