| 00:19.33 | *** join/#bzflag jh` (~jh_@83-102-62-236.bb.dnainternet.fi) |
| 00:25.44 | *** join/#bzflag tw1sted (~quassel@unaffiliated/tw1sted) |
| 00:59.35 | blast007 | hmm... misc/snap.sh "Generates a snapshot and patch of a sourceforge cvs project" ;D |
| 01:04.54 | jh` | good job man |
| 01:17.40 | *** join/#bzflag Pimpi (~frank@p4FF42BA5.dip0.t-ipconnect.de) |
| 02:26.48 | *** join/#bzflag joevano (~joevano@bzflag/developer/JoeVano) |
| 02:26.48 | *** mode/#bzflag [+v joevano] by ChanServ |
| 03:21.52 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 03:37.02 | *** join/#bzflag DTRemenak|RDP (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 03:37.02 | *** mode/#bzflag [+v DTRemenak|RDP] by ChanServ |
| 05:37.38 | BulletCatcher | It seems like further vsync changes at this time would be complicated with little benefit. |
| 05:37.38 | BulletCatcher | Let's focus on other things for 2.4.4. |
| 05:38.59 | BulletCatcher | BTW, we aren't really affected by the current SourceForge outage. :-) |
| 06:52.41 | *** join/#bzflag BZnotify (~BZnotify@192.30.252.40) |
| 06:52.41 | BZnotify | [13bzflag] 15JMakey pushed 3 new commits to 062.4: 02http://git.io/vmpYf |
| 06:52.41 | BZnotify | 13bzflag/062.4 14bed60d0 15Jeff Makey: Allow connections from port 1024, which isn't privileged. |
| 06:52.41 | BZnotify | 13bzflag/062.4 149f31ca6 15Jeff Makey: Use BZDB.evalInt() instead of casting BZDB.eval() to an int.... |
| 06:52.41 | BZnotify | 13bzflag/062.4 147474fd3 15Jeff Makey: Simplify a couple of CIDR calculations. |
| 06:52.41 | *** part/#bzflag BZnotify (~BZnotify@192.30.252.40) |
| 07:00.34 | *** join/#bzflag BZnotify (~BZnotify@192.30.252.45) |
| 07:00.35 | BZnotify | [13bzflag] 15JMakey pushed 1 new commit to 062.4: 02http://git.io/vmp35 |
| 07:00.35 | BZnotify | 13bzflag/062.4 1413f2d0d 15Jeff Makey: Simplify another CIDR calculation. |
| 07:00.35 | *** part/#bzflag BZnotify (~BZnotify@192.30.252.45) |
| 07:37.37 | *** join/#bzflag Constitution (~josh@bzflag/developer/Constitution) |
| 10:22.08 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 10:41.58 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 10:51.13 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 11:28.41 | blast007 | hmm, webReport works on Linux (when I fix it to use the correct loop variable name of "reports" instead of just "report" and add it to the build system), but on Windows it looks to be freeing memory as it passes the DLL boundary. Correctly pulls and reads a line of report data at https://github.com/BZFlag-Dev/bzflag/blob/2.4/plugins/webReport/webReport.cpp#L97 but comes out on ... |
| 11:28.47 | blast007 | ... https://github.com/BZFlag-Dev/bzflag/blob/2.4/src/bzfs/bzfsHTTPAPI.cxx#L2164 as repeating 0xEEFE. |
| 11:31.45 | blast007 | given that, it's highly unlikely that any of the HTTP plugins that use templates will work at all on Windows |
| 14:31.04 | BulletCatcher | Try changing WebReport::GetTemplateKey() to return strdup(reports->get(report).c_str()). |
| 14:31.05 | BulletCatcher | If that works we'll have to be careful to free() the string on the calling side (and strdup() all GetTemplateKey() return values). |
| 14:34.02 | BulletCatcher | Another solution might be to pass a storage area (maybe just a std::string) down to GetTemplateKey() as a place for its result. |
| 14:49.41 | blast007 | iirc, std::string is one we can't pass over the DLL boundary, which was the reason for the bz_ApiString stuff |
| 14:50.03 | blast007 | I tried passing a bz_ApiString though and had the same result, iirc |
| 14:54.50 | blast007 | and yes, that does work, BulletCatcher |
| 14:55.41 | blast007 | though we should see if we can handle calling strdup as part of one of the plugin classes that our HTTP plugins extend instead of requiring that plugin devs know to do that |
| 14:56.03 | BulletCatcher | It seems like passing a bz_ApiString into GetTemplateKey() from bzfsHTTPAPI ought to work, too, and is probably how it is meant to be used. |
| 14:56.59 | BulletCatcher | At least we have one way to do it. |
| 14:57.21 | BulletCatcher | One heap to rule them all... |
| 14:58.06 | blast007 | I'll have to try with bz_ApiString again and see what exactly it did |
| 15:02.42 | *** join/#bzflag DTRemenak|RDP (~DTRemenak@about/essy/CrazyCoder/DTRemenak) |
| 15:02.42 | *** mode/#bzflag [+v DTRemenak|RDP] by ChanServ |
| 15:08.10 | *** join/#bzflag AAA_awright_ (~aaa@2607:5300:60:7d4::1) |
| 15:11.10 | *** join/#bzflag I_Died_Once (~I_Died_On@unaffiliated/idiedonce/x-1828535) |
| 15:29.26 | blast007 | https://msdn.microsoft.com/en-us/library/ms235460.aspx?f=255&MSPPError=-2147217396 |
| 15:29.41 | blast007 | "A related problem can occur when you allocate memory (either explicitly with new or malloc, or implicitly with strdup, strstreambuf::str, and so on) and then pass a pointer across a DLL boundary to be freed. This can cause a memory access violation or heap corruption if the DLL and its users use different copies of the CRT libraries." |
| 15:30.16 | blast007 | CRT = C RunTime |
| 15:33.05 | BulletCatcher | Sigh. What ought to work in all cases is allocating memory outside of the DLL and writing to it within the DLL (via a passed in pointer). |
| 15:33.33 | BulletCatcher | We'd have to pass in the length, too. |
| 15:38.12 | BulletCatcher | Also, there is probably a way to do a callback from a DLL so the main program can safely copy from memory allocated within the DLL before it is released. |
| 15:47.22 | BulletCatcher | I wonder if C++11's unique_ptr feature would help. |
| 16:16.13 | *** join/#bzflag zuii (~akos@BC06BF93.catv.pool.telekom.hu) |
| 16:24.18 | *** join/#bzflag TD-Linux (~Thomas@about/essy/indecisive/TD-Linux) |
| 18:12.44 | *** join/#bzflag the_map (~the_map@ip72-208-169-89.ph.ph.cox.net) |
| 18:15.25 | *** join/#bzflag Kaelten (Kaelten@WoWUIDev/WoWAce/WoWIFA/CurseStaff/kaelten) |
| 19:21.11 | *** join/#bzflag the_map (~the_map@unaffiliated/the-map/x-1795707) |
| 21:30.01 | *** join/#bzflag zuii (~akos@BC06BF93.catv.pool.telekom.hu) |