Menu
▾
▴
pidgin-patches — Updates to the Gaim patches tracker
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(435) |
Dec
(252) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(177) |
Feb
(157) |
Mar
(187) |
Apr
(168) |
May
(127) |
Jun
(291) |
Jul
(38) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2005-03-25 19:26:48
|
Patches item #1117170, was opened at 2005-02-06 01:54 Message generated for change (Comment added) made by rlaager You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1117170&group_id=235 Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Richard Laager (rlaager) Assigned to: Tim Ringenbach (marv_sf) Summary: Buddy Pounce Slash Command Handling Initial Comment: This patch implements handling of slash commands in buddy pounces setup to send a message. ---------------------------------------------------------------------- >Comment By: Richard Laager (rlaager) Date: 2005-03-25 13:26 Message: Logged In: YES user_id=156487 I'm closing this because I know it's not implemented right. I was implementing this because someone wanted it. Since I don't have any personal interest in the issue, I'm just going to close this patch. I have more important patches to be working on. ---------------------------------------------------------------------- Comment By: Richard Laager (rlaager) Date: 2005-02-27 13:18 Message: Logged In: YES user_id=156487 marv_sf: I'm posting this here, so we don't forget: We need to talk about the right way to do this. I'm not terribly comfortable with the amount of code I had to copy and paste to make this patch. ---------------------------------------------------------------------- Comment By: Richard Laager (rlaager) Date: 2005-02-07 15:24 Message: Logged In: YES user_id=156487 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1117170&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-25 13:14:34
|
Patches item #1170377, was opened at 2005-03-25 02:24 Message generated for change (Settings changed) made by lschiere You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1170377&group_id=235 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Gary Kramlich (amc_grim) Assigned to: Nobody/Anonymous (nobody) Summary: Correctly update group counts in head Initial Comment: Correctly updates the group counts in HEAD when you sign off. I didn't do anything with current size since I'm not to familiar with the blist node stuff, but it does hide the groups now. I just updated the online member of the blistnode struct to reflect the account signing off. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1170377&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-25 13:13:26
|
Patches item #1170374, was opened at 2005-03-25 01:54 Message generated for change (Settings changed) made by lschiere You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1170374&group_id=235 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Gary Kramlich (amc_grim) Assigned to: Nobody/Anonymous (nobody) Summary: Jabber cleanups for buddy struct members Initial Comment: With the status rewrite we don't need some of these old legacy members in the buddy structure. I'm trying to clean them up by novell hasn't been ported to the new status, and I have nfi what I'm doing with novell.. So here's jabber. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1170374&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-25 13:12:28
|
Patches item #1170373, was opened at 2005-03-25 01:51 Message generated for change (Settings changed) made by lschiere You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1170373&group_id=235 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Gary Kramlich (amc_grim) Assigned to: Nobody/Anonymous (nobody) Summary: HEAD: irc warning fix.. Initial Comment: fixes a possibly uninitialized var in irc on HEAD ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1170373&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-25 13:11:14
|
Patches item #1170367, was opened at 2005-03-25 01:41 Message generated for change (Settings changed) made by lschiere You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1170367&group_id=235 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Gary Kramlich (amc_grim) Assigned to: Nobody/Anonymous (nobody) Summary: Napster tweaks for head Initial Comment: Some napster tweaks for head. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1170367&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-25 07:24:50
|
Patches item #1170377, was opened at 2005-03-25 01:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1170377&group_id=235 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gary Kramlich (amc_grim) Assigned to: Nobody/Anonymous (nobody) Summary: Correctly update group counts in head Initial Comment: Correctly updates the group counts in HEAD when you sign off. I didn't do anything with current size since I'm not to familiar with the blist node stuff, but it does hide the groups now. I just updated the online member of the blistnode struct to reflect the account signing off. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1170377&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-25 06:57:23
|
Patches item #1121104, was opened at 2005-02-12 09:41 Message generated for change (Comment added) made by bleeter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1121104&group_id=235 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bleeter Yaluser (bleeter) Assigned to: Tim Ringenbach (marv_sf) Summary: Yahoo privacy fixes Initial Comment: The yahoo prpl has no real concept of privacy, beyond what Yahoo servers offer. Here's a patch that addresses most of these issues. 1) Introduce a privacy check routine. Ideally, this should be in privacy.c, but it's esier to submit in here for the moment, for simple testing. If people think it's worthy to be added before complete privacy rewrite, it can be moved. 2) Each incoming message can be checked against this function. Thus, all typing, IMs and chat invites can be blocked. 3) The permit/deny list is now active. As yahoo protocol has no concept beyond blocking, this acts locally only. I've submitted to head, as although I believe this is actually a bugfix, it's best to submit here and backport (although it was written against oldstatus and forward poted originally) ---------------------------------------------------------------------- >Comment By: Bleeter Yaluser (bleeter) Date: 2005-03-25 17:57 Message: Logged In: YES user_id=407708 This patch missed checking privacy for audibles. Next patch will update this. ---------------------------------------------------------------------- Comment By: Bleeter Yaluser (bleeter) Date: 2005-03-17 14:25 Message: Logged In: YES user_id=407708 It would appear there's something deeply wrong with privacy, where 0 = 1. Go figure. ---------------------------------------------------------------------- Comment By: Bleeter Yaluser (bleeter) Date: 2005-03-09 13:12 Message: Logged In: YES user_id=407708 Ok, here's an initial 1.x patch. Comments welcome. I've done *some* tidying up. More comments welcome. ---------------------------------------------------------------------- Comment By: Bleeter Yaluser (bleeter) Date: 2005-03-09 11:02 Message: Logged In: YES user_id=407708 There's one more 'thing' I'd like to get in here, for ease of chat UI use. Give me a few hours. ---------------------------------------------------------------------- Comment By: Bleeter Yaluser (bleeter) Date: 2005-03-08 12:36 Message: Logged In: YES user_id=407708 Yes, I realised I'd not blocked chat invites after I posted this. I've added it to my later versions ;-) I did originally have buckets of debug in the code, but ripped most of it out for publishing. I'll put what you sugegst back in. Whitespace fix won't be a problem :-) I'd tried keeping formatting consistency with other gaim code, but as ou know, that's not always a useful guide ;-) Should have an update for you in 24 hours or so. Do you want a 1.x backport as well? Actually, it originates as a 1.x patch, and I forwardport. ---------------------------------------------------------------------- Comment By: Tim Ringenbach (marv_sf) Date: 2005-03-08 11:50 Message: Logged In: YES user_id=790708 Actually, you just block conference invites, not chat invites. You might want to block both. I don't suppose you could work in some kind of gaim_debug warning if we receive an IM from someone on the block list when we're in "block the users below"? Because we shouldn't be getting IM's from users like that, and covering up the bug will just make it harder to fix. (the bug being the people aren't ending up on the server side block list) Also, could you fix the whitespace? Like, the switch statement isn't indented at all. Nothing should be not indented at all except function names and the opening { for the function.. I do usually have the switch and the cases below it at the same indentation level, e.g.: switch () { case: default: } I don't know how right that is, or if gaim has a genereal rule for it though. Also, I usually put no space between a function and the (), like "printf("hello!");", but I always put a space if it's a flow control thingy, like "if (foo != bar) {" For multiline functions, something like <tab>printf("%s%s%s", <tab><space><space><space><space>blah, blah, blah); Is probably better, than multiple tabs. The important thing is the same number of tabs is used on both lines, so the line looks right whether the tab is 4 or 8 spaces. Also, you should probably use gaim_debug_info() instead of gaim_debug(GAIM_DEBUG_INFO) I think that's all the nit picking for now. If you fix at least some of what i complained about i'll apply it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1121104&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-25 06:54:17
|
Patches item #1170374, was opened at 2005-03-25 00:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1170374&group_id=235 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gary Kramlich (amc_grim) Assigned to: Nobody/Anonymous (nobody) Summary: Jabber cleanups for buddy struct members Initial Comment: With the status rewrite we don't need some of these old legacy members in the buddy structure. I'm trying to clean them up by novell hasn't been ported to the new status, and I have nfi what I'm doing with novell.. So here's jabber. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1170374&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-25 06:51:46
|
Patches item #1170373, was opened at 2005-03-25 00:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1170373&group_id=235 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gary Kramlich (amc_grim) Assigned to: Nobody/Anonymous (nobody) Summary: HEAD: irc warning fix.. Initial Comment: fixes a possibly uninitialized var in irc on HEAD ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1170373&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-25 06:41:10
|
Patches item #1170367, was opened at 2005-03-25 00:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1170367&group_id=235 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gary Kramlich (amc_grim) Assigned to: Nobody/Anonymous (nobody) Summary: Napster tweaks for head Initial Comment: Some napster tweaks for head. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1170367&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-24 12:57:48
|
Patches item #1169352, was opened at 2005-03-23 14:49 Message generated for change (Settings changed) made by lschiere You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1169352&group_id=235 Category: Plugins Group: None Status: Open Resolution: None Priority: 5 Submitted By: JulienC (juliencegarra) >Assigned to: Stu Tomlinson (nosnilmot) Summary: Nudge support Initial Comment: This patch add nudge support for the msn plugins (the same functionality for yahoo plugins was added few days ago). The diff is on gaim 2 cvs. Changelog : * Msn has the following new "/" command: /nudge (Julien Cegarra, Martin Bayard) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1169352&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-24 04:10:49
|
Patches item #1169415, was opened at 2005-03-23 16:00 Message generated for change (Comment added) made by thekingant You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1169415&group_id=235 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Eitan Isaacson (mjrtomjr) Assigned to: Nobody/Anonymous (nobody) Summary: msn http fix Initial Comment: this fixes the msn http method on 1.2.0 ---------------------------------------------------------------------- >Comment By: Mark Doliner (thekingant) Date: 2005-03-23 23:10 Message: Logged In: YES user_id=20979 I didn't test this at all, so if it doesn't work, I'm going to send my girlfriend's dog after you (it's a chihuahua!). Thanks for the patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1169415&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-23 21:00:16
|
Patches item #1169415, was opened at 2005-03-23 23:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1169415&group_id=235 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Eitan Isaacson (mjrtomjr) Assigned to: Nobody/Anonymous (nobody) Summary: msn http fix Initial Comment: this fixes the msn http method on 1.2.0 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1169415&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-23 19:49:35
|
Patches item #1169352, was opened at 2005-03-23 20:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1169352&group_id=235 Category: Plugins Group: None Status: Open Resolution: None Priority: 5 Submitted By: JulienC (juliencegarra) Assigned to: Nobody/Anonymous (nobody) Summary: Nudge support Initial Comment: This patch add nudge support for the msn plugins (the same functionality for yahoo plugins was added few days ago). The diff is on gaim 2 cvs. Changelog : * Msn has the following new "/" command: /nudge (Julien Cegarra, Martin Bayard) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1169352&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-23 05:29:09
|
Patches item #581335, was opened at 2002-07-14 15:55 Message generated for change (Settings changed) made by sourceo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=581335&group_id=235 Category: None Group: None >Status: Closed Resolution: Out of Date Priority: 5 Submitted By: Ari Pollak (sourceo) Assigned to: Etan Reisner (deryni9) Summary: Fix filectl.c Initial Comment: Don't run commands on startup in filectl.c, this has the possibility to be bad. ---------------------------------------------------------------------- Comment By: Ari Pollak (sourceo) Date: 2003-01-26 02:33 Message: Logged In: YES user_id=41611 This fixes filectl to work with the latest modifications to gaim, and also to eliminate warnings when compiling with latest glib. ---------------------------------------------------------------------- Comment By: Ari Pollak (sourceo) Date: 2002-08-28 23:48 Message: Logged In: YES user_id=41611 latest CVS patch, remove applet.h to allow it to compile. That line shouldn't have even been in there to begin with. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=581335&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-23 05:29:07
|
Patches item #581335, was opened at 2002-07-14 15:55 Message generated for change (Settings changed) made by sourceo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=581335&group_id=235 Category: None Group: None Status: Open >Resolution: Out of Date Priority: 5 Submitted By: Ari Pollak (sourceo) Assigned to: Etan Reisner (deryni9) Summary: Fix filectl.c Initial Comment: Don't run commands on startup in filectl.c, this has the possibility to be bad. ---------------------------------------------------------------------- Comment By: Ari Pollak (sourceo) Date: 2003-01-26 02:33 Message: Logged In: YES user_id=41611 This fixes filectl to work with the latest modifications to gaim, and also to eliminate warnings when compiling with latest glib. ---------------------------------------------------------------------- Comment By: Ari Pollak (sourceo) Date: 2002-08-28 23:48 Message: Logged In: YES user_id=41611 latest CVS patch, remove applet.h to allow it to compile. That line shouldn't have even been in there to begin with. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=581335&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-22 00:17:25
|
Patches item #1167921, was opened at 2005-03-21 17:06 Message generated for change (Settings changed) made by lschiere You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1167921&group_id=235 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Joao Luís Marques Pinto (jpinto) >Assigned to: Ethan Blanton (eblanton) Summary: IRC protocol - irc services alias Initial Comment: This patch adds the command /nickserv, /chanserv, /memoserv, /operserv, it is safer than the /msg option because more modern ircds will ensure that the message is routed to a service and not to a "fake" client. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1167921&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-22 00:17:04
|
Patches item #1167894, was opened at 2005-03-21 16:32 Message generated for change (Settings changed) made by lschiere You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1167894&group_id=235 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Joao Luís Marques Pinto (jpinto) >Assigned to: Ethan Blanton (eblanton) Summary: IRC, Support for 005 PREFIX Initial Comment: The following patch will extend the irc plugin with support for the chanmodes specifed on the PREFIX= message. Chanmodes will be stripped from nick's on /names . It will also map the prefix "." to room founder (I am not sure this is common). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1167894&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-21 22:06:42
|
Patches item #1167921, was opened at 2005-03-21 22:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1167921&group_id=235 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Joao Luís Marques Pinto (jpinto) Assigned to: Nobody/Anonymous (nobody) Summary: IRC protocol - irc services alias Initial Comment: This patch adds the command /nickserv, /chanserv, /memoserv, /operserv, it is safer than the /msg option because more modern ircds will ensure that the message is routed to a service and not to a "fake" client. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1167921&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-21 21:32:09
|
Patches item #1167894, was opened at 2005-03-21 21:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1167894&group_id=235 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Joao Luís Marques Pinto (jpinto) Assigned to: Nobody/Anonymous (nobody) Summary: IRC, Support for 005 PREFIX Initial Comment: The following patch will extend the irc plugin with support for the chanmodes specifed on the PREFIX= message. Chanmodes will be stripped from nick's on /names . It will also map the prefix "." to room founder (I am not sure this is common). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1167894&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-21 18:11:56
|
Patches item #1030243, was opened at 2004-09-18 01:46 Message generated for change (Settings changed) made by chrono86 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1030243&group_id=235 Category: segfault Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: rian hunter (chrono86) Assigned to: Ethan Blanton (eblanton) Summary: DNS child bad IPC on 64-bit Big endian Initial Comment: in the host_resolved function (parent) of src/proxy.c, it receives the dns information like this --------- int rc, err; (4 bytes on LP64) size_t addrlen; (8 bytes on some LP64 unices) operation, size read(childfd, &err, sizeof(err)); 4 read(childfd, &addrlen, sizeof(addrlen)); 8 read(childfd, &addr, addrlen); varies read(childfd, &addrlen, sizeof(addrlen)); 8 if addrlen == 0 then stop; -------- the child works like this: ----- const int zero = 0; (4 bytes LP64) size_t addrlen; (8 bytes on some LP64 unices); operation, size write(childfd, &zero, sizeof(zero)); 4 write(childfd, &addrlen, sizeof(addrlen)); 8 write(childfd, &addr, addrlen); varies write(childfd, &zero, sizeof(zero)); 4 -------- in the last read of host_resolved only the first 4 bytes are read, and in big endian, these are the MSB then the lower four bytes aren't cleared and addrlen will retain it's lower 32-bit value, and not evaluate to zero when it should. my patch changes err (in host resolved) and zero (in the child) to be size_t datatype. because addrlen in the child must be size_t bytes, so zero must be size_t, and if zero is size_t, then err must be size_t. ---------------------------------------------------------------------- Comment By: rian hunter (chrono86) Date: 2005-03-21 13:01 Message: Logged In: YES user_id=801658 Yeah it is, no one fixed it before though. I guess this one can be closed now. ---------------------------------------------------------------------- Comment By: Stu Tomlinson (nosnilmot) Date: 2005-03-21 10:00 Message: Logged In: YES user_id=309779 I think this is the same as what patch 1162827 fixed, right? ---------------------------------------------------------------------- Comment By: rian hunter (chrono86) Date: 2004-10-02 14:52 Message: Logged In: YES user_id=801658 This bug doesn't only affect Big Endian 64-Bit machines, but all 64-Bit machines if that was unclear. The bug is just more obvious on a 64-bit Big Endian machine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1030243&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-21 18:01:09
|
Patches item #1030243, was opened at 2004-09-18 01:46 Message generated for change (Comment added) made by chrono86 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1030243&group_id=235 Category: segfault Group: None >Status: Open Resolution: None Priority: 5 Submitted By: rian hunter (chrono86) Assigned to: Ethan Blanton (eblanton) Summary: DNS child bad IPC on 64-bit Big endian Initial Comment: in the host_resolved function (parent) of src/proxy.c, it receives the dns information like this --------- int rc, err; (4 bytes on LP64) size_t addrlen; (8 bytes on some LP64 unices) operation, size read(childfd, &err, sizeof(err)); 4 read(childfd, &addrlen, sizeof(addrlen)); 8 read(childfd, &addr, addrlen); varies read(childfd, &addrlen, sizeof(addrlen)); 8 if addrlen == 0 then stop; -------- the child works like this: ----- const int zero = 0; (4 bytes LP64) size_t addrlen; (8 bytes on some LP64 unices); operation, size write(childfd, &zero, sizeof(zero)); 4 write(childfd, &addrlen, sizeof(addrlen)); 8 write(childfd, &addr, addrlen); varies write(childfd, &zero, sizeof(zero)); 4 -------- in the last read of host_resolved only the first 4 bytes are read, and in big endian, these are the MSB then the lower four bytes aren't cleared and addrlen will retain it's lower 32-bit value, and not evaluate to zero when it should. my patch changes err (in host resolved) and zero (in the child) to be size_t datatype. because addrlen in the child must be size_t bytes, so zero must be size_t, and if zero is size_t, then err must be size_t. ---------------------------------------------------------------------- >Comment By: rian hunter (chrono86) Date: 2005-03-21 13:01 Message: Logged In: YES user_id=801658 Yeah it is, no one fixed it before though. I guess this one can be closed now. ---------------------------------------------------------------------- Comment By: Stu Tomlinson (nosnilmot) Date: 2005-03-21 10:00 Message: Logged In: YES user_id=309779 I think this is the same as what patch 1162827 fixed, right? ---------------------------------------------------------------------- Comment By: rian hunter (chrono86) Date: 2004-10-02 14:52 Message: Logged In: YES user_id=801658 This bug doesn't only affect Big Endian 64-Bit machines, but all 64-Bit machines if that was unclear. The bug is just more obvious on a 64-bit Big Endian machine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1030243&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-21 15:00:47
|
Patches item #1030243, was opened at 2004-09-18 01:46 Message generated for change (Comment added) made by nosnilmot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1030243&group_id=235 Category: segfault Group: None >Status: Pending Resolution: None Priority: 5 Submitted By: rian hunter (chrono86) Assigned to: Ethan Blanton (eblanton) Summary: DNS child bad IPC on 64-bit Big endian Initial Comment: in the host_resolved function (parent) of src/proxy.c, it receives the dns information like this --------- int rc, err; (4 bytes on LP64) size_t addrlen; (8 bytes on some LP64 unices) operation, size read(childfd, &err, sizeof(err)); 4 read(childfd, &addrlen, sizeof(addrlen)); 8 read(childfd, &addr, addrlen); varies read(childfd, &addrlen, sizeof(addrlen)); 8 if addrlen == 0 then stop; -------- the child works like this: ----- const int zero = 0; (4 bytes LP64) size_t addrlen; (8 bytes on some LP64 unices); operation, size write(childfd, &zero, sizeof(zero)); 4 write(childfd, &addrlen, sizeof(addrlen)); 8 write(childfd, &addr, addrlen); varies write(childfd, &zero, sizeof(zero)); 4 -------- in the last read of host_resolved only the first 4 bytes are read, and in big endian, these are the MSB then the lower four bytes aren't cleared and addrlen will retain it's lower 32-bit value, and not evaluate to zero when it should. my patch changes err (in host resolved) and zero (in the child) to be size_t datatype. because addrlen in the child must be size_t bytes, so zero must be size_t, and if zero is size_t, then err must be size_t. ---------------------------------------------------------------------- >Comment By: Stu Tomlinson (nosnilmot) Date: 2005-03-21 10:00 Message: Logged In: YES user_id=309779 I think this is the same as what patch 1162827 fixed, right? ---------------------------------------------------------------------- Comment By: rian hunter (chrono86) Date: 2004-10-02 14:52 Message: Logged In: YES user_id=801658 This bug doesn't only affect Big Endian 64-Bit machines, but all 64-Bit machines if that was unclear. The bug is just more obvious on a 64-bit Big Endian machine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1030243&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-21 13:24:49
|
Patches item #1162827, was opened at 2005-03-14 03:27 Message generated for change (Comment added) made by thekingant You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1162827&group_id=235 Category: None Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: rian hunter (chrono86) Assigned to: Mark Doliner (thekingant) Summary: 64bit IPC dns child bug Initial Comment: In proxy.c the dns child sends an int, size_t, an array of chars, (more size_ts, and char arrays), then an int. The problem with this protocol is that in 64 bit UNIX implementations, size_t is implemented as an 8 byte integer, whereas int is still 4 bytes. This conflicts with the while loop in the client function host_resolved: --- snip while(rc > 0) { rc=read(req->fd_out, &addrlen, sizeof(addrlen)); if(rc>0 && addrlen > 0) { addr=g_malloc(addrlen); rc=read(req->fd_out, addr, addrlen); hosts = g_slist_append(hosts, GINT_TO_POINTER(addrlen)); hosts = g_slist_append(hosts, addr); } else { break; } } -- snip The while loop depends on reading 8 bytes = 0 at a time to stop, but the dns child has been ending its request with only 4 bytes (the int). This patch declares a new constant in the gaim_dns_childthread function called "endzero" of type size_t (to match addrlen). The childthread now ends each dns request with endzero (8 bytes) instead of zero (4 bytes), so the client isn't waiting on the child forever. ---------------------------------------------------------------------- >Comment By: Mark Doliner (thekingant) Date: 2005-03-21 08:24 Message: Logged In: YES user_id=20979 Goody. Thanks again for finding this ---------------------------------------------------------------------- Comment By: rian hunter (chrono86) Date: 2005-03-21 02:57 Message: Logged In: YES user_id=801658 Ah, the current file in CVS looks correct. Thanks a lot for fixing this! ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-03-20 14:43 Message: Logged In: YES user_id=20979 Hmm, I have a feeling you weren't really looking at the current file in CVS (there's a ~5 hour delay between anonymous and developer CVS). I changed it so that rc is always sent (as a 4 byte int), and the size_t 0 is no longer sent before the char array. So the case where rc = 0 should look like this. 1. 4 Byte int, (rc) 2. 8 Byte size_t, * Byte char array, (repeat n times) 3. 8 Byte size_t (zero) Or am I still missing something? ---------------------------------------------------------------------- Comment By: rian hunter (chrono86) Date: 2005-03-20 14:34 Message: Logged In: YES user_id=801658 Sorry but I just looked through your changes and what you have in CVS still isnt' right either. I'll be very descriptive. The important part of the host_resolved function is from line 325 to line 316. This is the transaction it expects: 1. Read an int (4 bytes) (might be an error code) 2. If int is zero (this is the case we are worried about) and we just read more than zero bytes bytes then start the address loop. 3. Read a size_t, then read size_t bytes, keep doing this until the original size_t is 0. So on a 64bit machine the transaction wants to be this: 1. 4 Byte int 2. 8 Byte size_t, * Byte char array (repeat n times) 3. stop when the size_t = 0. But in the gaim_dns_childthread you chaned zero to a size_t, this isn't entirely correct because if rc != 0 (line 482) then the childthread sends an int error code, if not it sends a zero size_t. This is inconsistent. In the case where rc = 0, the transaction it sends is this: 1. 8 Byte size_t 2. 8 Byte size_t, * Byte char array, (repeat n times) 3. 8 Byte size_t Do you see the inconsistency? As long the host_resolved function is originally reading an int as the value to test for success or not, you can't just send the first zero as a size_t. That's why my patch is the way it is, it only ends with a size_t. ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-03-20 13:04 Message: Logged In: YES user_id=20979 Ok, no, an int isn't right either. I changed zero back to a size_t. The data sent from the child to the parent looks like this: int rc (regardless of whether rc is zero or non-zero) size_t addrlen char* addr (repeat addrlen and char*) size_t zero ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-03-20 12:15 Message: Logged In: YES user_id=20979 Good point, I didn't really look at the code the first time. Changing "zero" to an int should work. I'll just do that, instead. ---------------------------------------------------------------------- Comment By: rian hunter (chrono86) Date: 2005-03-19 22:24 Message: Logged In: YES user_id=801658 I don't think you can solve the problem by simply changing zero to a size_t. If you look at the host_resolved function, it reads a 4-byte error code that could also be the initial zero (which if made to be a size_t would be 8 bytes on those UNIX systems). That was the reason behind making a new constant called endzero. If you make zero a size_t you should play with the host_resolved function to make sure it correlates. ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-03-19 21:06 Message: Logged In: YES user_id=20979 I just fixed this in oldstatus (1.2.1) and head (2.0). I ending up changing zero from an int to a size_t. That should work, right? Thanks for tracking this down. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1162827&group_id=235 |
|
From: SourceForge.net <no...@so...> - 2005-03-21 07:57:43
|
Patches item #1162827, was opened at 2005-03-14 03:27 Message generated for change (Comment added) made by chrono86 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1162827&group_id=235 Category: None Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: rian hunter (chrono86) Assigned to: Mark Doliner (thekingant) Summary: 64bit IPC dns child bug Initial Comment: In proxy.c the dns child sends an int, size_t, an array of chars, (more size_ts, and char arrays), then an int. The problem with this protocol is that in 64 bit UNIX implementations, size_t is implemented as an 8 byte integer, whereas int is still 4 bytes. This conflicts with the while loop in the client function host_resolved: --- snip while(rc > 0) { rc=read(req->fd_out, &addrlen, sizeof(addrlen)); if(rc>0 && addrlen > 0) { addr=g_malloc(addrlen); rc=read(req->fd_out, addr, addrlen); hosts = g_slist_append(hosts, GINT_TO_POINTER(addrlen)); hosts = g_slist_append(hosts, addr); } else { break; } } -- snip The while loop depends on reading 8 bytes = 0 at a time to stop, but the dns child has been ending its request with only 4 bytes (the int). This patch declares a new constant in the gaim_dns_childthread function called "endzero" of type size_t (to match addrlen). The childthread now ends each dns request with endzero (8 bytes) instead of zero (4 bytes), so the client isn't waiting on the child forever. ---------------------------------------------------------------------- >Comment By: rian hunter (chrono86) Date: 2005-03-21 02:57 Message: Logged In: YES user_id=801658 Ah, the current file in CVS looks correct. Thanks a lot for fixing this! ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-03-20 14:43 Message: Logged In: YES user_id=20979 Hmm, I have a feeling you weren't really looking at the current file in CVS (there's a ~5 hour delay between anonymous and developer CVS). I changed it so that rc is always sent (as a 4 byte int), and the size_t 0 is no longer sent before the char array. So the case where rc = 0 should look like this. 1. 4 Byte int, (rc) 2. 8 Byte size_t, * Byte char array, (repeat n times) 3. 8 Byte size_t (zero) Or am I still missing something? ---------------------------------------------------------------------- Comment By: rian hunter (chrono86) Date: 2005-03-20 14:34 Message: Logged In: YES user_id=801658 Sorry but I just looked through your changes and what you have in CVS still isnt' right either. I'll be very descriptive. The important part of the host_resolved function is from line 325 to line 316. This is the transaction it expects: 1. Read an int (4 bytes) (might be an error code) 2. If int is zero (this is the case we are worried about) and we just read more than zero bytes bytes then start the address loop. 3. Read a size_t, then read size_t bytes, keep doing this until the original size_t is 0. So on a 64bit machine the transaction wants to be this: 1. 4 Byte int 2. 8 Byte size_t, * Byte char array (repeat n times) 3. stop when the size_t = 0. But in the gaim_dns_childthread you chaned zero to a size_t, this isn't entirely correct because if rc != 0 (line 482) then the childthread sends an int error code, if not it sends a zero size_t. This is inconsistent. In the case where rc = 0, the transaction it sends is this: 1. 8 Byte size_t 2. 8 Byte size_t, * Byte char array, (repeat n times) 3. 8 Byte size_t Do you see the inconsistency? As long the host_resolved function is originally reading an int as the value to test for success or not, you can't just send the first zero as a size_t. That's why my patch is the way it is, it only ends with a size_t. ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-03-20 13:04 Message: Logged In: YES user_id=20979 Ok, no, an int isn't right either. I changed zero back to a size_t. The data sent from the child to the parent looks like this: int rc (regardless of whether rc is zero or non-zero) size_t addrlen char* addr (repeat addrlen and char*) size_t zero ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-03-20 12:15 Message: Logged In: YES user_id=20979 Good point, I didn't really look at the code the first time. Changing "zero" to an int should work. I'll just do that, instead. ---------------------------------------------------------------------- Comment By: rian hunter (chrono86) Date: 2005-03-19 22:24 Message: Logged In: YES user_id=801658 I don't think you can solve the problem by simply changing zero to a size_t. If you look at the host_resolved function, it reads a 4-byte error code that could also be the initial zero (which if made to be a size_t would be 8 bytes on those UNIX systems). That was the reason behind making a new constant called endzero. If you make zero a size_t you should play with the host_resolved function to make sure it correlates. ---------------------------------------------------------------------- Comment By: Mark Doliner (thekingant) Date: 2005-03-19 21:06 Message: Logged In: YES user_id=20979 I just fixed this in oldstatus (1.2.1) and head (2.0). I ending up changing zero from an int to a size_t. That should work, right? Thanks for tracking this down. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300235&aid=1162827&group_id=235 |
3 messages has been excluded from this view by a project administrator.
