Last 5000 messages. Note that DCNF is not responsible for comments made by individuals that freely visit the hub. [2023-11-11 16:26:59] np you're right [2023-11-11 16:27:45] you can still have them with the right compromise, for a few more months at least [2023-11-11 17:09:41] GTK4 is reall that bad? [2023-11-11 17:10:42] Their text editor example sums it up quite nicely: https://docs.gtk.org/gtk4/getting-started-app9.png [2023-11-11 17:11:33] ew [2023-11-11 17:50:28] you should use VSCode [2023-11-11 18:36:15] anywho if anyone would like to make their icon set I will gladly add the option in right now to load your own icons [2023-11-11 18:36:44] but there are 2 issues with this. dwt (UI toolkit used by DC++) does not cache icons [2023-11-11 18:37:46] and because it doesn't cache the icons they will constantly be reloaded e.g look at the settings dialog when you close or destroy it, the icons used are not cached so everytime you open the settings dialog the icons will be reloaded [2023-11-11 18:38:26] which is the double edged sword I am stuck with because A) you can instantly see icon changes on the fly as long you reload the resource [2023-11-11 18:38:36] B) it can be slower on older systems and setups [2023-11-20 18:08:10] hi [2023-11-25 17:51:15] I hate rtf [2023-11-25 17:51:29] but you sure can make it look purdy [2023-12-02 00:35:35] . [2023-12-02 00:44:09] .. [2023-12-02 00:44:56] , [2023-12-02 06:41:05] hello [2023-12-23 13:43:28] Happy Christmas :) [2023-12-27 18:47:02] <[-TE-]-RoLex> mornings [2023-12-27 18:48:04] <[-TE-]-RoLex> i have a question about scriptplugin for dc++ > https://code.launchpad.net/~dcplusplus-team/dcpp-plugin-sdk-cpp/ScriptPlugin < is this source same as compiled plugin here > https://sourceforge.net/projects/dcplusplus/files/Plugins/ScriptPlugin/ ? [2023-12-27 18:50:00] <[-TE-]-RoLex> does anyone know if there are other modifications in compiled version? i need to know this because i need to add another function to the plugin, but make sure that rest of functionality works the same way [2023-12-27 18:51:15] <[-TE-]-RoLex> so nothing get broken simply [2023-12-27 18:51:35] <[-TE-]-RoLex> too bad that https://sourceforge.net/projects/dcplusplus/files/Plugins/ScriptPlugin/ doesnt include source code its based on [2023-12-27 18:52:18] <[-TE-]-RoLex> iceman50: you also had done some work on lua plugin or im wrong? [2023-12-27 22:08:49] we arfe discussing the update for it [2023-12-27 22:09:00] when i say we i mean me myself and i [2023-12-27 22:20:25] short answer is yes I'll update it assuming I don't get much problems [2023-12-27 22:21:01] how fast that will be depends on how fast I finish what I'm doing right now [2023-12-28 07:40:38] https://dcplusplus.sourceforge.io/plugins.html points to the actual source code of each released plugin. Info is in the bottom of the page. [2023-12-28 09:37:59] <[-TE-]-RoLex> oh, thats where they hide. damn i didnt see the little text on the bottom of the page. thanks emtee =) [2023-12-28 09:53:07] yw [2023-12-28 10:13:06] <[-TE-]-RoLex> so many plans on the lua plugin, adding luasockets atleast, for ability to fetch urls. or maybe even use dcpps internal http handler, but i guess it will involve synchronizing threads so whole client doesnt freeze while retrieving data [2023-12-28 12:55:36] there's already an internal handler for HTTP and plugins [2023-12-28 12:55:43] see the DataAccessor class [2023-12-28 12:59:18] void PluginApiImpl::getHTTPResource(const char* uri, const char* localPath) { [2023-12-28 13:14:44] <[-TE-]-RoLex> super [2023-12-28 16:23:23] <[-TE-]-RoLex> wtf [2023-12-28 16:23:30] <[-TE-]-RoLex> --------------------------- Scripting plugin --------------------------- Cannot install the plugin: Error loading ScriptPlugin-x64.dll: The specified module could not be found. --------------------------- OK --------------------------- [2023-12-28 16:24:35] <[-TE-]-RoLex> i dont understand what module is talks about. the dll is right there [2023-12-28 16:24:44] <[-TE-]-RoLex> is = it * [2023-12-28 16:58:32] <[-TE-]-RoLex> this must be due to different lua version in current scriptplugin repo [2023-12-28 16:59:19] <[-TE-]-RoLex> i didnt change anything at all, just compiled the source [2023-12-28 20:36:40] <[-TE-]-RoLex> finally. its the damn libwinpthread dll that was not linked, had same issue with dcpp on my cygwin setup [2023-12-28 20:41:05] <[-TE-]-RoLex> *** Scripts (Lua 5.3.1) are using 6,37 MiB of system memory [2023-12-28 20:41:33] <[-TE-]-RoLex> this is latest commit from the files on sourceforge [2023-12-28 20:42:00] <[-TE-]-RoLex> while precompiled is lua 5.2.1 :-P [2023-12-28 20:59:46] <[-TE-]-RoLex> *** Scripts (Lua 5.4.6) are using 5,86 MiB of system memory =) [2023-12-28 22:34:06] <[-TE-]-RoLex> hahaha. are you kidding me about LuaExeс shit? who invented this?? :-D [2023-12-28 22:36:33] <[-TE-]-RoLex> or do i have to write another https://te-home.net/?id=54&title=Second+largest+exploit+in+NMDC+history about how users send their Favorites.xml to my server revealing all the passwords? :-D [2023-12-28 22:37:44] <[-TE-]-RoLex> if this happened 3-4 years ago, i would :-P but now i let you fix this before people start to figure out :-D [2023-12-28 22:39:23] <[-TE-]-RoLex> i dont blame dcpp devs, but those BCDC enthusiasts from 2000's who made things without thinking [2023-12-28 22:40:17] <[-TE-]-RoLex> its like writing a php script that connects to mysql database with direct input without escaping - so beginner mistake :-P [2023-12-28 22:46:20] <[-TE-]-RoLex> i didnt think that i would find another critical exploit in dc in 2023>2024, but i did. lol [2023-12-28 22:47:23] <[-TE-]-RoLex> welcome to team elite thinking :-P [2023-12-28 22:58:11] <[-TE-]-RoLex> maybe time to update lua lib at the same time? is it possible to automatically replace ScriptPlugin.dll on dcpp version update? i think it is because Plugins dir is a subdir of dcpp root. apexdc needs to do this for sure, (win)airdc probably not? they seem to use js instead [2023-12-28 23:07:38] <[-TE-]-RoLex> sometimes it feels like whole dc thing between ~2001-2010 was "pure" backdoor implementation by "poor" special agents, lol [2023-12-28 23:29:53] <[-TE-]-RoLex> maybe thats the mistery of suddenly disappearing favorites.xml back in 2007-2009 which noone else could reproduce and apexdc even had to implement a backup function for all xml files, because this issue inherits from those days as i can see :-D [2023-12-28 23:43:50] a plugin updater [2023-12-28 23:44:25] i hadn't thought of it since i just build my own dcext once compiled [2023-12-29 00:22:58] oh I hadn't realized there was a backup plugin [2023-12-29 00:31:16] probably my favorite part is the sheer confidence displayed in "Make BCDC's Lua user commands work... hopefully" [2023-12-29 07:38:18] hello [2023-12-29 12:09:48] <[-TE-]-RoLex> mornings [2023-12-29 12:24:38] <[-TE-]-RoLex> should i make a patch ? [2023-12-29 12:26:29] sure if you like to [2023-12-29 12:33:11] since you seem to be one of the few actually running that plugin you probably want your data to be safe, no? [2023-12-29 12:48:53] <[-TE-]-RoLex> yes, ofcourse. i got interested if apexdc ever had this plugin enabled by default, in older versions specificly [2023-12-29 12:51:54] <[-TE-]-RoLex> i can make patch for plugin itself (new version), but not a dc++ recommendation on upgrading version 1,00 due to vuln. can this even be acomplished? kind of plugin updater as iceman suggested [2023-12-29 12:56:01] yeah it can be done, question is whether it is a priority at all [2023-12-29 12:56:12] given the download stats of the DC++ plugin repo this plugin's usage ratio seems to be very low [2023-12-29 12:57:24] I can't tell about apex but that client is not updated for at least 10 years and can be taken out several ways remotely so if anyone still uses it they don't care security at all anyway [2023-12-29 12:57:46] the latest apex should have the same plugin interface as DC++ I believe [2023-12-29 13:00:31] if you play with it and come up with something that's able to answer how much percent of the public dc clients have this plugin enabled and from those how many are up to date clients then don't keep that info for yoursef [2023-12-29 13:06:11] <[-TE-]-RoLex> i wont keep for myself, else i would not have told you this at all. instead i would go checking every admin on all 280 hubs left alive today :-P [2023-12-29 13:39:14] <[-TE-]-RoLex> but i just got pretty much concerned about what you said about priority. lets speak dc++ alone now .. you know that there is a backdoor/RCE in one of extensions that your project advertises and fully supports, but you wont tell the users of your project that they might be in danger, even if they are few - those few are usually lua enthusiasts - your colleagues with other words. there is no other priority in dc++, the only things done on the project lately is make-up and ssl upodates. there is plenty space for a simple plugin updater with priority notifications. in fact dc++ already notifies its users about fraudulent hublists - which are not dangerous at all actually. or lets say ctm protection list. i dont think that you resonate/prioritize correctly here. it hurts to be looked at, in my eyes atleast - who is involved so mach into exploitation and security [2023-12-29 13:40:48] <[-TE-]-RoLex> much * [2023-12-29 14:43:12] I didn't intend to play down the seriousness of the issue it's rather about the reality of how things working these days around DC++. I meant priority as to fix the issue, commit and properly release an updated plugin. Lets hope some people in the team able do it soon then everythings OK, I am probably unable to in the forthcoming few months... [2023-12-29 14:56:35] <[-TE-]-RoLex> aha, you are out of the clocks. well, dc++ team is still big. i heard cologic has plenty of time :-P [2023-12-29 14:56:49] <[-TE-]-RoLex> i can help probably [2023-12-29 14:57:02] <[-TE-]-RoLex> almost done with patch [2023-12-29 15:07:04] <[-TE-]-RoLex> lol. patch file is 3,5 mb in size :-D should i make a zip instead and share? new is > latest lua lib, copyright header update, gpl 2>3, luаехес removed [2023-12-29 17:31:06] agree with all of those changes. yeah, maybe a .zip is better [2023-12-29 17:31:54] In theory, it's possible to sandbox Lua, but probably there's no feasible fix as such without redesigning the API more than is worthwhile. The most correct answer is probably just remove that functionality of at least hub-supplied Lua usercommands as terminally broken/conceptually flawed. There's also an in-band signaling where LuaExec is passed from the ScriptPlugin to the script host within the network channel. In hindsight a bad idea, probably an outgrowth of my preference 20 years ago for a "narrow waist" kind of API [didn't know about that phrase then, it's been used/somewhat recently popularized by the person leading the Oil shell development, e.g,. https://www.oilshell.org/blog/2022/02/diagrams.html https://www.oilshell.org/blog/2023/06/narrow-waist.html etc) where in general the whole API is designed to be small and "narrow" in the sense of, everything is homogenized into a single representation, the network representation. So the way this LuaExec gets passed around is as part of injected/simulated network traffic (Plugin::onHubDataOut). Which turned out to be less elegant than one might hope because it's still basically specialized just in a not-well-documented way as a way to almost RPC Lua calls, RCE as a service. [2023-12-29 18:15:21] <[-TE-]-RoLex> <[-TE-]-RoLex> https://ledo.feardc.net/misc/ScriptPlugin-1.1.zip < here is my fix anyway. new is > latest lua lib, copyright header update, gpl 2>3, luаехес removed <[-TE-]-RoLex> brb, load fixed plugin for testing <[-TE-]-RoLex> btw, forgot to tell. you (or someone) will have to compile the new dll. im not sure that my cygwin builer will compile something that works on all computers <[-TE-]-RoLex> im waiting for my new pc in january, then i can set it up properly again <[-TE-]-RoLex> i think the easiest solution to "keep" luаеxec is to forward outgoing messages to lua (i made a commented code in my zip), only need to collect listeners in startup.lua. then a lua script can choose whether to broadcast message to hub or not, and instead evaluate required code if needed <[-TE-]-RoLex> i just modified my plugin for this and currently testing <[-TE-]-RoLex> the only important thing plugin devs need to watch over in this case, is only to make sure that badly written scripts dont get in default scripts repository <[-TE-]-RoLex> i dont think that repository will ever change anyway. its up to each plugin user to modify them [2023-12-29 18:15:56] <[-TE-]-RoLex> sorry, not sure where to communicate. its not like i was invited to your discussion :-P [2023-12-29 18:58:09] <[-TE-]-RoLex> i just moved modified plugin to github > https://github.com/RoLex/dc-plugins [2023-12-29 19:01:00] <[-TE-]-RoLex> here is what i was talking about > https://github.com/RoLex/dc-plugins/blob/main/ScriptPlugin/src/Plugin.cpp#L348-L349 [2023-12-29 19:01:59] <[-TE-]-RoLex> (equals letting script author to accept or deny luаеxec or what ever he likes) [2023-12-29 19:17:15] <[-TE-]-RoLex> cologic: when you talk usercommands - this is only one of the ways to use it, there are more ways :-P [2023-12-29 19:18:04] <[-TE-]-RoLex> there is one that doesnt require you to actually click a user command menu in order to execute :-P [2023-12-29 19:18:39] <[-TE-]-RoLex> but yes, usercommands was the start point of reverse engeneering [2023-12-29 19:21:13] RoLeX: sure, that was the design intention. But it'll captre any LuaExec in outgoing traffic [2023-12-29 19:24:41] <[-TE-]-RoLex> im currently working in a poc. dunno where to share it though [2023-12-29 19:25:03] <[-TE-]-RoLex> dont want to reach all eyes :-P [2023-12-29 19:34:51] <[-TE-]-RoLex> do you have a place? discord perhaps? =) [2023-12-29 19:35:15] <[-TE-]-RoLex> jesus. how modern did we get .. discord i say .. there is pm on dc [2023-12-29 19:35:16] <[-TE-]-RoLex> lol [2023-12-29 19:35:26] <[-TE-]-RoLex> :-D :-D [2023-12-29 19:35:33] <[-TE-]-RoLex> mind if i join your pm ? [2023-12-29 19:37:23] <[-TE-]-RoLex> i dont have many frinds left that i could share a laugh with, you could be that person today. lol [2023-12-29 19:37:29] <[-TE-]-RoLex> its friday anyway [2023-12-29 19:40:28] sure [2023-12-29 19:41:00] for PM here at least [2023-12-30 10:00:34] The poc can be shared e.g. in the lp bug tracker, in a ticket set to private security. [2023-12-30 10:42:25] <[-TE-]-RoLex> mornings [2023-12-30 10:43:42] <[-TE-]-RoLex> do you really want to see the poc? its creepy :-D [2023-12-30 10:47:13] <[-TE-]-RoLex> how to make an lp private ? [2023-12-30 10:48:02] <[-TE-]-RoLex> i see [2023-12-30 10:48:05] <[-TE-]-RoLex> This bug is a security vulnerability [2023-12-30 16:24:31] <[-TE-]-RoLex> jesus launchpad sucks. or im too noob to find how to activate [code] and [color] tags? [2023-12-30 16:28:03] <[-TE-]-RoLex> i made the poc report anyway [2023-12-30 16:28:53] <[-TE-]-RoLex> needed a couple of hours on finding the perfect way of doing this :-D [2023-12-30 16:29:10] <[-TE-]-RoLex> also there are less perfect that are not mentioned :-P [2023-12-30 16:29:11] <[-TE-]-RoLex> bbl [2024-01-01 01:00:22] <[-TE-]-RoLex> hny! [2024-01-01 01:01:20] happy new year [2024-01-01 09:10:12] hny all [2024-01-01 14:44:59] Happy New Years [2024-01-01 14:45:20] :) [2024-01-01 15:26:00] happy new years [2024-01-01 21:19:39] happy new year all [2024-01-02 04:27:02] LuaExec has been removed from ScriptPlugin: https://sourceforge.net/p/dcnetwork/code/ci/c3c681a07798fb7c5da2c0aae8995690284735d2/ [2024-01-02 16:49:44] <[-TE-]-RoLex> mornings [2024-01-02 16:50:24] <[-TE-]-RoLex> cologic: i added solution for bitops in comment #7 [2024-01-02 21:07:42] RoLex: well, my hope was to end up at a "clean" Lua 5.4 setup (no bitos library at all). But yeah, I can see what you proposed working: add a shim, which can then be removed. It's kind of socially easier never to have it than add it then remove it, and unless the removal is done, the net result is IMO worse [2024-01-02 21:07:54] *bitops library [2024-01-02 21:08:31] I doubt it's actually used, it's just the risk, and that it's fundamentally on a different testing timeline/priority [2024-01-02 21:10:53] i.e. is Lua 5.4+shim, then maybe/ideally Lua 5.4 without shim, better than just 5.3 (no shim) to 5.4 (also no shim) [2024-01-02 23:31:46] If the only problem is bitops, I'd recommend documenting how to address the issue if needed. [2024-01-03 01:18:57] klondike long time no see [2024-01-03 01:19:02] you lurker, you [2024-01-03 02:42:16] RoLex: checked more closely and you're right about this, and Lua 5.4 is almost certainly fine (basically, I'd assumed the 5.2 backwards compatibility had been enabled and it hadn't been/isn't) [2024-01-03 02:43:02] The Debian builds of the Lua REPL/interpreter enable it, but not the library built by the ScriptPlugin [2024-01-03 02:45:32] I'd already a few days ago checked the rest of this: "Checked the dcnetwork ScriptPlugin Lua version, per discussion a while ago, and https://sourceforge.net/p/dcnetwork/code/ci/default/tree/trunk/dc-plugins/ScriptPlugin/lua/ was per commit message updated to Lua 5.3.1 in 2015, so only https://www.lua.org/manual/5.4/manual.html#8 is potentially relevant. For "8.3 – Incompatibilities in the API", lua_newuserdata is used but the Lua 5.4.6 lua.h already defines a compatibility macro: "#define lua_newuserdata(L,s) lua_newuserdatauv(L,s,1)" per " For compatibility, the old names still work as macros assuming one single user value". lua_setuservalue and lua_getuservalue aren't used in the dcnetwork repository." [2024-01-03 02:45:42] "lua_resume and lua_version aren't used in the dcnetwork repository, either, nor are LUA_ERRGCMM, LUA_GCSETPAUSE, or LUA_GCSETSTEPMUL. Thus, Lua 5.4 has no relevant API compatibility issues compared with the already-used 5.3.1." [2024-01-03 02:46:25] "Regarding "8.2 – Incompatibilities in the Libraries", the print/tostring thing is relatively harmless; wouldn't worry about it. Changing the math.random algorithm is transparent for any DC plugins. The utf8 library only gains functionality. setpause/setstepmul, which have been deprecated aren't used in the dcnetwork repository. Regardless, Lua 5.4.6's luaB_collectgarbage in lbaselib.c still implements them, so safe regardless. The io.lines change is the only thing I'd wonder a bit about -- it's not used in the dcnetwork repo, and it's probably not used much in this context, but the fix/workaround is very simple, "To fix that issue, you can wrap the call into parentheses, to adjust its number of results to one.", and compatible with 5.3. So IMO worth the (small) risk. That's it for "8.2 – Incompatibilities in the Libraries"" [2024-01-03 02:49:04] See comment #8 for a more detailed analysis. [2024-01-03 02:50:23] klondike: fortunately, looks like no such documentation will be necessary. [2024-01-03 02:56:25] iceman50: I was stupid enough to volunteer for a thing, that ate a lot of my time. [2024-01-03 02:56:38] Really, never do a PhD you'll live longer :P [2024-01-03 02:57:15] cologic: I'll do so. [2024-01-03 03:41:05] Oh, actual text of this comment #8, https://pastebin.com/2KrFjHB5 [2024-01-03 03:44:57] The ScriptPlugin has been updated to use Lua 5.4.6: https://sourceforge.net/p/dcnetwork/code/ci/a5253d7f87c25ea4162a3b7678be74be335926d0/ [2024-01-04 00:19:08] klondike: I will keep that in mind :p [2024-01-04 05:46:21] hello [2024-01-04 05:46:23] :) [2024-01-04 16:33:15] <[-TE-]-RoLex> mornings [2024-01-05 08:34:30] tmux a [2024-01-05 08:36:08] er. [2024-01-06 15:35:42] hi [2024-01-16 06:55:19] <[-TE-]-RoLex> mornings [2024-01-20 07:47:16] <[-TE-]-RoLex> mornings [2024-01-20 14:45:31] morning [2024-01-20 15:11:26] <[-TE-]-RoLex> i think its right time to test new dev plugin. mostly because old dev plugin can use gigabytes of ram when enabled and run in background for days :) [2024-01-20 15:13:02] <[-TE-]-RoLex> i sure understand why it does. if the message list never gets truncated to specific limit, it has to memorize the lines somewhere :-P [2024-01-20 15:15:53] <[-TE-]-RoLex> oh, and thanks for adding me to "maintained projects" list. it would be cool if my nick was written correctly though :-P [2024-01-20 17:03:55] The dev plugin i already knew about [2024-01-20 17:04:17] I only maintain my version which just so happens to mirrored as the official version which I'm fine with [2024-01-20 17:04:41] once i fix a few things in this client I'm just going to start working on 1.3 or 1.23 or who knows [2024-01-21 08:57:09] <[-TE-]-RoLex> mornings [2024-01-21 13:44:18] morn [2024-01-24 10:54:40] <[-TE-]-RoLex> mornings [2024-01-26 15:25:14] <[-TE-]-RoLex> mornings [2024-01-28 09:47:57] <[-TE-]-RoLex> mornings [2024-02-03 07:49:46] <[-TE-]-RoLex> mornings [2024-02-03 12:01:13] morn [2024-02-04 07:30:34] <[-TE-]-RoLex> mornings [2024-02-08 10:36:47] <[-TE-]-RoLex> mornings [2024-02-15 15:30:01] <[-TE-]-RoLex> mornings [2024-02-17 06:58:34] hello [2024-02-17 07:08:00] Aleksiej Nawalny is DEAD [2024-02-17 07:08:07] :( [2024-02-22 14:10:18] morning [2024-02-22 20:47:17] ok, back online.. sorry everyone :) [2024-02-22 21:13:34] oops wrong chat -- sorry [2024-02-22 21:13:40] my hubs were down :D [2024-02-23 13:23:59] <[-TE-]-RoLex> mornings [2024-03-01 16:01:20] <[-TE-]-RoLex> mornings [2024-03-03 07:15:07] <[-TE-]-RoLex> you don't have a brain... dc++ doesn't work on verlihub [2024-03-03 07:15:09] <[-TE-]-RoLex> mornings [2024-03-03 07:15:26] <[-TE-]-RoLex> can anyone confirm this? [2024-03-03 07:16:52] <[-TE-]-RoLex> i mean the second part ofcourse :-D [2024-03-03 08:26:34] I am continously logged on to VerliHubs, one is the latest version (I think) the other is a pretty old version. No issues for years. [2024-03-03 08:28:32] A bit more details on client / hub versions and the nature of the problem and then... [2024-03-04 08:09:05] hello [2024-03-04 08:09:09] :) [2024-03-05 16:24:49] <[-TE-]-RoLex> thanks [2024-03-06 01:06:39] I wonder what a pain it is to build verli [2024-03-06 01:06:52] i need to test more stuff any ways [2024-03-07 16:27:44] <[-TE-]-RoLex> building vh is very simple. what os ? [2024-03-08 01:42:06] Win 11 [2024-03-08 01:42:36] (mind you I haven't looked into it at all I like to keep a rotation of hubsofts I'm using for testing my stuff) [2024-03-08 01:42:59] Also I'm rewriting the DevPlugin UI stuff [2024-03-08 19:17:03] <[-TE-]-RoLex> oh, windows. that is easy too > https://ubuntu.com/desktop/wsl [2024-03-08 19:17:56] <[-TE-]-RoLex> you will get native linux in windows console, or even gui if you install x11 [2024-03-08 19:21:08] <[-TE-]-RoLex> i did a few performance tests .. wsl is about 20% slower than real linux. that is due to virtualization [2024-03-08 19:21:26] <[-TE-]-RoLex> depends on type of tasks ofcourse [2024-03-08 23:21:44] ah no native win support [2024-03-09 19:41:25] <[-TE-]-RoLex> damn, just saw dcpp commits for past 6-9 months, there is alot to follow up :-D [2024-03-09 19:44:37] <[-TE-]-RoLex> got most interested in dwarf4 flags in sconstruct. it doesnt mean that dwarf was updated to version 4, does it? [2024-03-09 19:44:53] <[-TE-]-RoLex> because i tried that without success [2024-03-09 19:47:06] <[-TE-]-RoLex> that was the only lib i didnt manage to update. sould be nice to do so > https://www.prevanders.net/dwarfbug.html [2024-03-09 19:59:16] <[-TE-]-RoLex> would * [2024-03-10 09:10:03] RoLex, https://bugs.launchpad.net/dcplusplus/+bug/2039677 [2024-03-10 11:05:42] hi all [2024-03-13 17:54:15] <[-TE-]-RoLex> eMTee: thanks. cool icons btw =) im in progress of getting up to date, soon there :-P [2024-03-13 23:50:01] | Libs | Boost version: 1_83 | ZLib version: 1.3 | BZip2 version: 1.0.8, 13-Jul-2019 | OpenSSL version: 3.2.1 - 30 Jan 2024 | MiniUPnPc version: 2.2.5 | SdEx version: 1.06 | GeoIP2 version: 1.9.1 [2024-03-13 23:50:05] i need to update [2024-03-13 23:50:30] OpenSSL is gonna be a pain to re-set up everything again [2024-03-14 18:16:03] <[-TE-]-RoLex> is that bdc++ ice ? [2024-03-14 18:16:39] <[-TE-]-RoLex> you use geoip2 =) [2024-03-14 18:17:12] <[-TE-]-RoLex> finally someone else implemented it. so now we are 3 - airdc, your client and feardc [2024-03-14 18:18:04] <[-TE-]-RoLex> bwt zlib latest is 1.3.1, i just upgraded [2024-03-14 18:18:14] <[-TE-]-RoLex> they found some fucked up bug [2024-03-14 18:18:17] <[-TE-]-RoLex> btw * [2024-03-14 23:25:39] sounds about right [2024-03-15 00:43:10] <[-TE-]-RoLex> damn, i have problems launching feardc after dc++ 881 merge > Compiled with MinGW-w64's GCC 11.4.0 (x64) Exception code: c0000005 Windows version: major = 10, minor = 0, build = 22631, SP = 0, type = 1 FearDC: [libdwarf error: DW_DLE_VERSION_STAMP_ERROR (48)] ? FearDC: [libdwarf error: DW_DLE_VERSION_STAMP_ERROR (48)] ? FearDC: [libdwarf error: DW_DLE_VERSION_STAMP_ERROR (48)] ? FearDC: [libdwarf error: DW_DLE_VERSION_STAMP_ERROR (48)] ? FearDC: [libdwarf error: DW_DLE_VERSION_STAMP_ERROR (48)] ? FearDC: [libdwarf error: DW_DLE_VERSION_STAMP_ERROR (48)] ? FearDC: [libdwarf error: DW_DLE_VERSION_STAMP_ERROR (48)] ? FearDC: [libdwarf error: DW_DLE_VERSION_STAMP_ERROR (48)] ? FearDC: [libdwarf error: DW_DLE_VERSION_STAMP_ERROR (48)] ? FearDC: [libdwarf error: DW_DLE_VERSION_STAMP_ERROR (48)] ? FearDC: [libdwarf error: DW_DLE_VERSION_STAMP_ERROR (48)] ? FearDC: [libdwarf error: DW_DLE_VERSION_STAMP_ERROR (48)] ? KERNEL32: [Failed to load the debugging data into memory (error: 2)] BaseThreadInitThunk ntdll: [Failed to load the debugging data into memory (error: 2)] RtlUserThreadStart [2024-03-15 00:43:49] <[-TE-]-RoLex> im not sure if this is related to my mingw setup or changed code [2024-03-15 00:44:17] <[-TE-]-RoLex> ive reainstalled cygwin+mingw since new pc arrived [2024-03-15 00:47:22] <[-TE-]-RoLex> will make a debug version tomorrow [2024-03-15 09:02:28] <[-TE-]-RoLex> >FearDC.exe Adding new directory Games Adding new directory Music Adding new directory Archives Adding new directory Videos initWindow initTabs initMenu initToolbar initStatusBar .. then instant crash without message or stack trace :-D [2024-03-15 09:05:57] <[-TE-]-RoLex> aha, it the new handleTaskbarOverlay() [2024-03-15 09:07:21] <[-TE-]-RoLex> if (!SETTING(DISABLE_TASKBAR_MENU)) tabs->initTaskbar(this); [2024-03-15 09:07:37] <[-TE-]-RoLex> this is my own mod. taskbar is not initiated [2024-03-15 09:08:16] <[-TE-]-RoLex> but the big question here emtee, is that debug flags are not readable - the ones you fixed in dcpp [2024-03-15 09:09:10] hmm [2024-03-15 09:12:28] We didn't touch the debug info generation at all. [2024-03-15 09:13:38] <[-TE-]-RoLex> [2024-03-10 09:10:03] RoLex, https://bugs.launchpad.net/dcplusplus/+bug/2039677 [2024-03-15 09:14:14] Yeah, that's about fixing the already read info [2024-03-15 09:14:30] No change on how to read the info out of the pdb file [2024-03-15 09:14:40] <[-TE-]-RoLex> aha [2024-03-15 09:15:42] iceman tested it, it works on the msvc build, too. With all the shiny new memory relocations and whatnot... [2024-03-15 09:15:54] aye [2024-03-15 09:16:15] what compiler you work with, even? [2024-03-15 09:16:56] <[-TE-]-RoLex> Compiled with MinGW-w64's GCC 11.4.0 (x64) [2024-03-15 09:17:40] your libdwarf version is the same old one what's in DC++, right? [2024-03-15 09:18:08] <[-TE-]-RoLex> yes [2024-03-15 09:19:02] <[-TE-]-RoLex> now client dont crash anyway, doing handleTaskbarOverlay() on setting condition [2024-03-15 09:19:07] How does the crashlog look like? Any error message in it? [2024-03-15 09:19:32] <[-TE-]-RoLex> aha, i thought you saw it in history .. moment [2024-03-15 09:19:58] <[-TE-]-RoLex> Compiled with MinGW-w64's GCC 11.4.0 (debug) (x64) Exception code: c0000005 Windows version: major = 10, minor = 0, build = 22631, SP = 0, type = 1 FearDC: [libdwarf error: DW_DLE_VERSION_STAMP_ERROR (48)] ? FearDC: [libdwarf error: DW_DLE_VERSION_STAMP_ERROR (48)] ? FearDC: [libdwarf error: DW_DLE_VERSION_STAMP_ERROR (48)] ? FearDC: [libdwarf error: DW_DLE_VERSION_STAMP_ERROR (48)] ? FearDC: [libdwarf error: DW_DLE_VERSION_STAMP_ERROR (48)] ? FearDC: [libdwarf error: DW_DLE_VERSION_STAMP_ERROR (48)] ? FearDC: [libdwarf error: DW_DLE_VERSION_STAMP_ERROR (48)] ? FearDC: [libdwarf error: DW_DLE_VERSION_STAMP_ERROR (48)] ? FearDC: [libdwarf error: DW_DLE_VERSION_STAMP_ERROR (48)] ? FearDC: [libdwarf error: DW_DLE_VERSION_STAMP_ERROR (48)] ? FearDC: [libdwarf error: DW_DLE_VERSION_STAMP_ERROR (48)] ? FearDC: [libdwarf error: DW_DLE_VERSION_STAMP_ERROR (48)] ? FearDC: [libdwarf error: DW_DLE_VERSION_STAMP_ERROR (48)] ? KERNEL32: [Failed to load the debugging data into memory (error: 2)] BaseThreadInitThunk ntdll: [Failed to load the debugging data into memory (error: 2)] RtlUserThreadStart [2024-03-15 09:20:19] what about your binutils version [2024-03-15 09:21:11] Also there's a change in libdwarf config for *sprintf behavior of the newer MinGW [2024-03-15 09:21:55] <[-TE-]-RoLex> GNU windres (GNU Binutils) 2.42 [2024-03-15 09:22:58] row 4 - 8 in https://sourceforge.net/p/dcplusplus/code/ci/default/tree/dwarf/config.h [2024-03-15 09:24:57] https://sourceforge.net/p/dcplusplus/code/ci/99e4afdce86f595dbabf61770c3e24cf20f61aa5/tree/dwarf/config.h?diff=43196df8283bc3dfadc8eebd665c55804cef8954 [2024-03-15 09:25:26] make sure this change is merged [2024-03-15 09:27:14] <[-TE-]-RoLex> it is. i merged absolutely everything > https://github.com/RoLex/feardc/commit/1f2b374a39bcd33411768bc98dd86093ced97d9b [2024-03-15 09:30:39] <[-TE-]-RoLex> i will play around anyway. something is different this time [2024-03-15 09:30:55] <[-TE-]-RoLex> also pdb grew to 360 mb [2024-03-15 09:31:03] <[-TE-]-RoLex> old one was 280 [2024-03-15 09:37:30] yeah, that's crazy [2024-03-15 09:40:43] you can generate a much more size-friendly .pdb file with cv2pdb and it will work [2024-03-15 09:41:13] additional step for release but then you can get rid of libdwarf if you like [2024-03-15 09:43:26] <[-TE-]-RoLex> https://gcc.gnu.org/gcc-11/changes.html > For targets that produce DWARF debugging information GCC now defaults to DWARF version 5 (with the exception of VxWorks and Darwin/Mac OS X which default to version 2 and AIX which defaults to version 4). This can produce up to 25% more compact debug information compared to earlier versions. To take full advantage of DWARF version 5 GCC needs to be built against binutils version 2.35.2 or higher. When GCC is built against earlier versions of binutils GCC will still emit DWARF version 5 for most debuginfo data, but will generate version 4 debug line tables (even when explicitly given -gdwarf-5). The following debug information consumers can process DWARF version 5: GDB 8.0, or higher valgrind 3.17.0 elfutils 0.172, or higher (for use with systemtap, dwarves/pahole, perf and libabigail) dwz 0.14 Programs embedding libbacktrace are urged to upgrade to the version shipping with GCC 11. To make GCC 11 generate an older DWARF version use -g together with -gdwarf-2, -gdwarf-3 or -gdwarf-4. [2024-03-15 09:47:09] <[-TE-]-RoLex> in dcpp you have only "-gdwarf-4", not "-g" + "-gdwarf-4" [2024-03-15 09:47:16] <[-TE-]-RoLex> i will test this [2024-03-15 09:49:17] Well, see the bug report [2024-03-15 09:50:03] gcc's own docs are not 100% apply to various MinGW builds [2024-03-15 09:50:25] they do differ in many areas in linker and other configurations [2024-03-15 09:54:06] even though gcc docs are split for unix and windows, I've found many items and descriptions of behavior do not apply to the specific MinGW-W64 we use. [2024-03-15 10:00:34] <[-TE-]-RoLex> =) [2024-03-15 10:00:53] <[-TE-]-RoLex> i will try another attepmt of updating libdwarf [2024-03-15 10:01:07] <[-TE-]-RoLex> dont remember now what the problem was last time [2024-03-15 10:02:26] up to some 2018-19 release it looks to be probably usable without changes, a matter of a test [2024-03-15 10:03:06] newer releases have a major restructure which probably needs more alignment [2024-03-15 10:58:14] a libdward update will require some changes to the CrashLogger so keep that in mind [2024-03-15 10:58:22] libdwarf* even [2024-03-15 11:41:17] <[-TE-]-RoLex> ofcourse, new dwarf is much different [2024-03-15 11:43:24] <[-TE-]-RoLex> i have a different type of question .. dcpp uses boost, which has so much stuff including boost stacktrace - why dont use it? [2024-03-15 11:58:57] to be honest with you I'm not sure the reasoning, but all things considered I'm sure poy had a very good reasoning for creating the CrashLogger the way he did with regards to MinGW [2024-03-15 11:59:16] as for me, I use MSVC [2024-03-15 12:09:52] maybe there was no boost::stacktrace back then, 13 years ago [2024-03-15 12:18:14] <[-TE-]-RoLex> probably, yes. whole main.cpp uses try-catch block - exactly what is needed for boost stacktrace =) [2024-03-15 12:20:00] alright. good catch anyway [2024-03-15 13:19:37] <[-TE-]-RoLex> to use boost stacktrace, we still need libbacktrace. not even cygwin package manager includes it, there is no such lib or devel mentioned :-D [2024-03-15 13:19:55] <[-TE-]-RoLex> i guess it is indeed easier to use dwarf [2024-03-15 13:20:59] <[-TE-]-RoLex> there is source code though > https://github.com/ianlancetaylor/libbacktrace < and boost explaining how to use it > https://www.boost.org/doc/libs/1_84_0/doc/html/stacktrace/configuration_and_build.html [2024-03-15 13:36:23] it's still an alternative good to know about [2024-03-15 13:58:14] <[-TE-]-RoLex> hehe > https://bugs.launchpad.net/dcplusplus/+bug/189241/comments/11 [2024-03-15 13:59:24] <[-TE-]-RoLex> here is the libdwarf answer > https://bugs.launchpad.net/dcplusplus/+bug/189241/comments/14 [2024-03-15 14:00:08] <[-TE-]-RoLex> "this hasn't been easy as this is apparently the first public non-ELF use of libdwarf; but it has been very interesting. :)" - lol [2024-03-15 14:00:19] <[-TE-]-RoLex> he smiles too :-D [2024-03-15 14:17:06] I similarly have never thought that I'd ever understand how it works and even fix a bug in it :P [2024-03-15 17:12:06] <[-TE-]-RoLex> just tried that for 4 hours now, about half way there :-D [2024-03-15 17:12:27] <[-TE-]-RoLex> that is only CrashLogger.cpp code, untested, lol [2024-03-15 17:12:44] <[-TE-]-RoLex> but its not something i want to do on a friday evening :-P [2024-03-15 17:12:54] <[-TE-]-RoLex> so brb buy some beer [2024-03-15 17:54:55] <[-TE-]-RoLex> emtee, iceman, what is your binutils version btw? [2024-03-15 19:06:15] <[-TE-]-RoLex> im going to next level, installing msys2 instead of cygwin64, used that about 5 years ago. package manager seems alot more friendly and all packages required to build dcpp seems present out of the box. no need to install python for windows, or even gettext utils separately [2024-03-15 19:09:36] <[-TE-]-RoLex> this is what i like more rether than using custom mingw builds - install required stuff and go ahead with compiling [2024-03-15 19:13:32] <[-TE-]-RoLex> anyway, lets see how it behaves. i will start with compiling original dcpp 881 source but make same mistake - skip initializing taskbar, so i can gat to same crash point [2024-03-15 19:14:25] <[-TE-]-RoLex> rather * [2024-03-15 19:17:01] <[-TE-]-RoLex> damn, sf.net has become so slow with all their ads. it takes 4 minutes to download dcpp sourse - 63 mb :/ [2024-03-15 23:10:18] or you can just convert your mingw generated pdb and convert it to MSVC and then it works fine :P [2024-03-16 08:54:53] <[-TE-]-RoLex> yeah, but would be cool to get my mingw setup fixed too :-P what version of binutils did you have? i think the problem is my strip [2024-03-16 09:00:36] GNU strip (GNU Binutils) 2.37 <- in the official compiler [2024-03-16 12:08:20] <[-TE-]-RoLex> thanks for info. in currently trying msys2 instead [2024-03-16 12:08:24] <[-TE-]-RoLex> im * [2024-03-16 14:18:34] <[-TE-]-RoLex> DC++ version: DC++ v0.881 ("[unknown]") TTH: 5QWQLSTN5XZVZOYPTWIAE3W4PIZS2YR3NDUUGWQ Compiled with MinGW-w64's GCC 13.2.0 (x64) Exception code: c0000005 Windows version: major = 10, minor = 0, build = 22631, SP = 0, type = 1 Processors: 16 * x64 System memory installed: 31,22 GiB Writing the stack trace... DCPlusPlus: [libdwarf error: DW_DLE_VERSION_STAMP_ERROR (48)] ? DCPlusPlus: [libdwarf error: DW_DLE_VERSION_STAMP_ERROR (48)] ? DCPlusPlus: [libdwarf error: DW_DLE_VERSION_STAMP_ERROR (48)] ? DCPlusPlus: [libdwarf error: DW_DLE_VERSION_STAMP_ERROR (48)] ? DCPlusPlus: [libdwarf error: DW_DLE_VERSION_STAMP_ERROR (48)] ? DCPlusPlus: [libdwarf error: DW_DLE_VERSION_STAMP_ERROR (48)] ? DCPlusPlus: [libdwarf error: DW_DLE_VERSION_STAMP_ERROR (48)] ? DCPlusPlus: [libdwarf error: DW_DLE_VERSION_STAMP_ERROR (48)] ? DCPlusPlus: [libdwarf error: DW_DLE_VERSION_STAMP_ERROR (48)] ? DCPlusPlus: [libdwarf error: DW_DLE_VERSION_STAMP_ERROR (48)] ? DCPlusPlus: [libdwarf error: DW_DLE_VERSION_STAMP_ERROR (48)] ? DCPlusPlus: [libdwarf error: DW_DLE_VERSION_STAMP_ERROR (48)] ? KERNEL32: [Failed to load the debugging data into memory (error: 2)] BaseThreadInitThunk ntdll: [Failed to load the debugging data into memory (error: 2)] RtlUserThreadStart [2024-03-16 14:18:38] <[-TE-]-RoLex> same crap, lol [2024-03-16 14:19:01] <[-TE-]-RoLex> thi is original unmodified dc++ source build under msys2 [2024-03-16 14:24:06] <[-TE-]-RoLex> there is only one thing left to test .. get an older version of strip [2024-03-16 14:24:23] <[-TE-]-RoLex> i wonder where i can get a precompiled version [2024-03-16 14:38:07] <[-TE-]-RoLex> https://sourceforge.net/projects/mingw/files/MinGW/Base/binutils/binutils-2.28/ < these dont do anything [2024-03-16 14:38:17] <[-TE-]-RoLex> no output, no pdb, lol [2024-03-16 14:38:25] <[-TE-]-RoLex> cant even --version, nothing happens [2024-03-16 14:45:05] you sure the issue is line endings in pdb [2024-03-16 14:45:36] <[-TE-]-RoLex> no, not at all [2024-03-16 14:45:53] <[-TE-]-RoLex> just trying to generate pdb with older version on strip, for testing [2024-03-16 14:46:01] <[-TE-]-RoLex> but i cant find strip that works [2024-03-16 14:46:41] <[-TE-]-RoLex> i have to start somewhere :-D [2024-03-16 14:50:53] <[-TE-]-RoLex> https://github.com/Microsoft/microsoft-pdb/blob/master/cvdump/cvdump.exe < >cvdump DCPlusPlus.pdb Microsoft (R) Debugging Information Dumper Version 14.00.23611 Copyright (C) Microsoft Corporation. All rights reserved. No CodeView format debug information available [2024-03-16 14:54:20] what does cv2pdb say? [2024-03-16 14:55:35] (it needs some msvc .dlls) [2024-03-16 15:09:21] <[-TE-]-RoLex> exactly i dont have these dlls [2024-03-16 15:09:54] they come with an msvc installation? [2024-03-16 15:34:32] <[-TE-]-RoLex> C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\dbh.exe DCPlusPlus.pdb dump error 0x2 loading DCPlusPlus.pdb C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\dbh.exe AirDC.pdb dump AirDC bio_nread0 649340 D:\CFILES\Projects\WinSSL\openssl-3.0.8-temp_64\crypto\bio\bss_bio.c 201 crypto\bio\libcrypto-lib-bss_bio.obj AirDC leveldb::PutVarint32 85c4b0 C:\Projects\airdc-git\leveldb\util\coding.cc 49 C:\Projects\airdc-git\vc14\x64\Release\LevelDB\coding.obj AirDC ossl_decode_der_dsa_sig 6f5900 D:\CFILES\Projects\WinSSL\openssl-3.0.8-temp_64\crypto\asn1_dsa.c 235 crypto\libcrypto-lib-asn1_dsa.obj C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\dbh.exe FearDC.pdb dump error 0x2 loading FearDC.pdb [2024-03-16 15:35:11] <[-TE-]-RoLex> DCPlusPlus.pdb < this is 0.881 from https://sourceforge.net/projects/dcplusplus/files/DC%2B%2B%200.881/DCPlusPlus-0.881-x64.zip/download [2024-03-16 15:35:55] <[-TE-]-RoLex> FearDC.pdb < my last compiled with cygwin/msys [2024-03-16 15:36:12] yeah sure they're not in the MS / Windows .pdb format [2024-03-16 15:37:05] <[-TE-]-RoLex> they are in efi format ? [2024-03-16 15:37:21] Windows is COFF format IIRC, you need DWARF to be able to parse with libdwarf [2024-03-16 15:38:16] or you create a COFF or whatever Windows format with cv2pdb and then Crashlogger.cpp will parse it using Win32 calls [2024-03-16 15:39:03] so you don't need libdwarf then [2024-03-16 15:39:23] this I've been trying to explain to you for a couple of days [2024-03-16 15:40:44] also your pdb will be 5 times smaller [2024-03-16 15:41:22] you work with msvc, have it installed so producing a .pdb for your release takes 10 seconds [2024-03-16 15:43:55] unless you want to figure out why cygwin / msys pdb is wrong - most probably because it is generated in a unix environment and you have to tell the compiler to produce the right kind of debug symbols [2024-03-16 15:44:15] <[-TE-]-RoLex> i understand that ofcourse. didnt know that windows generated different format [2024-03-16 15:44:28] and yes, it is not documented in stock gcc, it is specified by the toolchain [2024-03-16 15:45:06] <[-TE-]-RoLex> thats what im trying to figure out, why my toolchain doesnt generate correct debug data [2024-03-16 15:45:16] apparently, yeah [2024-03-16 15:53:06] cv2pdb :D [2024-03-16 15:57:02] <[-TE-]-RoLex> haha [2024-03-16 15:57:18] are you using any different linker flags? [2024-03-16 15:58:56] <[-TE-]-RoLex> i compiled dc++ 0.881 source as is, same problem [2024-03-16 15:59:35] release and debug x86 and x64 ? [2024-03-16 15:59:43] all have the same issue [2024-03-16 15:59:45] right? [2024-03-16 15:59:46] <[-TE-]-RoLex> only x64 release [2024-03-16 15:59:53] <[-TE-]-RoLex> i didnt try the other ones [2024-03-16 15:59:58] ah ok [2024-03-16 16:00:03] <[-TE-]-RoLex> should i ? [2024-03-16 16:00:14] it's always worth marking off your list [2024-03-16 16:00:41] <[-TE-]-RoLex> okay, ill do both [2024-03-16 16:00:44] and seriously see if cv2pdb gets it to work [2024-03-16 16:00:51] because you can further isolate [2024-03-16 16:01:30] <[-TE-]-RoLex> for that i need msvc, dont have that installed [2024-03-16 16:01:41] zip them up and send them to me [2024-03-16 16:01:47] ill do it for you if you want [2024-03-16 16:03:57] <[-TE-]-RoLex> https://ledo.feardc.net/misc/FearDC.zip < exe + pdb [2024-03-16 16:04:09] <[-TE-]-RoLex> or you need unstripped exe too ? [2024-03-16 16:04:17] nah just the pdb will be fine [2024-03-16 16:04:22] <[-TE-]-RoLex> k [2024-03-16 16:07:29] ooh an error [2024-03-16 16:07:42] X:\Projects\cv2pdb-0.52\bin\Debug>cv2pdb X:\Downloads\FearDC\FearDC.pdb X:\Downloads\FearDC\FearDC.pdb: Can't create file [2024-03-16 16:08:00] let me see what MSVC does [2024-03-16 16:08:05] how do i make it crash [2024-03-16 16:09:01] <[-TE-]-RoLex> lol. that is working version. let me make a buggy one :-D [2024-03-16 16:09:02] <[-TE-]-RoLex> moment [2024-03-16 16:10:09] make it unstripped [2024-03-16 16:10:20] <[-TE-]-RoLex> k [2024-03-16 16:26:41] <[-TE-]-RoLex> https://ledo.feardc.net/misc/FearDCun.zip [2024-03-16 16:31:05] grabbing [2024-03-16 16:31:18] can't connect [2024-03-16 16:32:34] yeah no bueno connecion [2024-03-16 16:33:59] enter https://ledo.feardc.net to the same tab and then hit the back button [2024-03-16 16:34:51] it offers the download for me then [2024-03-16 16:34:53] ok [2024-03-16 16:35:00] i got the stripped pdb [2024-03-16 16:35:18] it comes in at 41,851 KB [2024-03-16 16:35:44] so I was wrong it is rather no bueno server configuracion :P [2024-03-16 16:38:07] https://gofile.io/d/Kzttjc [2024-03-16 16:38:15] theres your pdb file [2024-03-16 17:21:22] <[-TE-]-RoLex> try now [2024-03-16 17:21:26] <[-TE-]-RoLex> sorry had server issues [2024-03-16 17:21:48] he got it the way I found [2024-03-16 17:22:20] i put the link of the pdb up there [2024-03-16 17:25:03] <[-TE-]-RoLex> what was the problem ? [2024-03-16 17:25:55] see the history [2024-03-16 17:26:25] at least for what was the solution [2024-03-16 17:26:29] not sure it's not really verbose in the error but im guessing it works better with unstripped exes (obviously) [2024-03-16 17:28:44] <[-TE-]-RoLex> i dont see what the problem was after reading history [2024-03-16 17:28:55] <[-TE-]-RoLex> or what the solution was [2024-03-16 17:29:46] he got the file finally [2024-03-16 17:30:01] <[-TE-]-RoLex> yes, i can see that. i dloaded icemans zip [2024-03-16 17:30:29] so try a crash using that [2024-03-16 17:31:48] libdwarf will give some error and then it'll be parsed as a msvc pdb file by crashlogger.cpp [2024-03-16 17:32:30] <[-TE-]-RoLex> FearDC: [Failed to load the debugging data into memory (error: 11)] dwt\src\Taskbar.cpp (186:0), function: setOverlayIcon FearDC: [Failed to load the debugging data into memory (error: 11)] boost\boost\smart_ptr\intrusive_ptr.hpp (98:0), function: handleTaskbarOverlay FearDC: [Failed to load the debugging data into memory (error: 11)] win32\MainWindow.cpp (550:0), function: initStatusBar FearDC: [Failed to load the debugging data into memory (error: 11)] win32\MainWindow.cpp (136:0), function: MainWindow FearDC: [Failed to load the debugging data into memory (error: 11)] win32\main.cpp (161:0), function: _M_invoke FearDC: [Failed to load the debugging data into memory (error: 11)] C:\MSys64\mingw64\include\c++\13.2.0\bits\std_function.h (241:0), function: dispatchAsync FearDC: [Failed to load the debugging data into memory (error: 11)] dwt\src\Application.cpp (180:8), function: dispatch FearDC: [Failed to load the debugging data into memory (error: 11)] dwt\src\Application.cpp (148:0), function: run FearDC: [Failed to load the debugging data into memory (error: 11)] .\dcpp\Thread.h (51:0), function: dwtMain FearDC: [Failed to load the debugging data into memory (error: 11)] dwt\src\Application.cpp (296:0), function: WinMain FearDC: [Failed to load the debugging data into memory (error: 11)] C:\M\B\src\mingw-w64\mingw-w64-crt\crt\crtexe.c (268:0), function: __tmainCRTStartup FearDC: [Failed to load the debugging data into memory (error: 11)] C:\M\B\src\mingw-w64\mingw-w64-crt\crt\crtexe.c (159:0), function: WinMainCRTStartup KERNEL32: [Failed to load the debugging data into memory (error: 2)] BaseThreadInitThunk ntdll: [Failed to load the debugging data into memory (error: 2)] RtlUserThreadStart [2024-03-16 17:33:09] thats it [2024-03-16 17:33:13] <[-TE-]-RoLex> but this doesnt resolve my issue :-D [2024-03-16 17:33:20] <[-TE-]-RoLex> thanks for your help ice := [2024-03-16 17:33:23] <[-TE-]-RoLex> :) * [2024-03-16 17:33:29] why this is a good crashlog [2024-03-16 17:33:45] remove libdwarf and errors will go [2024-03-16 17:34:02] <[-TE-]-RoLex> i know what the bug is because i compiled it intentionally [2024-03-16 17:34:30] <[-TE-]-RoLex> i want to find out why to compiles makes bad pdb, lol [2024-03-16 17:34:42] <[-TE-]-RoLex> we have a great misunderstanding here [2024-03-16 17:34:54] <[-TE-]-RoLex> compiler * [2024-03-16 17:35:04] yep but this is useful info still [2024-03-16 17:35:05] <[-TE-]-RoLex> my compiler * [2024-03-16 17:35:23] <[-TE-]-RoLex> what exactly is useful info? [2024-03-16 17:35:31] the pdb your compiler generates has the right debug symbols [2024-03-16 17:35:38] <[-TE-]-RoLex> aha [2024-03-16 17:35:48] it's just some format issue, nothing else [2024-03-16 17:36:06] <[-TE-]-RoLex> but the compiler/linker is causing this, or strip ? [2024-03-16 17:36:11] <[-TE-]-RoLex> or we dont know? [2024-03-16 17:38:09] that's what the process of elimination does [2024-03-16 17:39:25] Not sure. Maybe your compiler has dwarf 4 generation functions removed and it ignores -gdwarf4 [2024-03-16 17:39:45] make a pdb without -gdwarf4 and see if it differs [2024-03-16 17:41:19] <[-TE-]-RoLex> they differ is size, yes. i have tries all possibilities of flags .. went down to dwarf2, but still same result [2024-03-16 17:41:25] <[-TE-]-RoLex> in size * [2024-03-16 17:47:16] odd [2024-03-16 18:39:22] <[-TE-]-RoLex> very =) [2024-03-16 18:40:07] oh I need to finish building these project files so i can just build from VS [2024-03-16 18:40:22] <[-TE-]-RoLex> emtee, can you please point to your exact change that made chashlogger work again on your build ? [2024-03-16 18:40:57] <[-TE-]-RoLex> im not sure that its just -gdwarf4 flag [2024-03-16 18:41:57] <[-TE-]-RoLex> ice: does msvc compiling work out of the box? only need to generate msvc project files, right ? [2024-03-16 18:42:39] it has for me kbut scons doesn't produce setup with options [2024-03-16 18:42:47] it only runs an nmake command [2024-03-16 18:43:03] https://sourceforge.net/p/dcplusplus/code/ci/99e4afdce86f595dbabf61770c3e24cf20f61aa5/ [2024-03-16 18:43:09] also it was that revision [2024-03-16 18:51:00] rolex, see the bug report. I detailed everything there. [2024-03-16 18:52:16] in the beginning I also thought it is strip or binutils, various -g options, etc... [2024-03-16 18:52:55] what if you try to compile DC++ 0.880? [2024-03-16 18:53:59] I think it'll fail the same way [2024-03-16 18:55:04] the error you get - libdwarf can't even determine the dwarf version in the pdb... [2024-03-16 18:55:20] it has nothing to do with any change I have made last year [2024-03-16 18:56:30] at least what I think [2024-03-16 19:06:59] also try to revert the old sprintf define stuff in libdwarf. Sounds odd but maybe your compiler is using the old way - it's also set in the toolchain configured crt and does not depend on gcc or its actual version. [2024-03-16 19:08:08] <[-TE-]-RoLex> thats what im thinking. ive gone that far in this issue, that i satrt digging backwands in implementation [2024-03-16 19:08:20] <[-TE-]-RoLex> for example > DWORD and DWORD_PTR on 64 bit machine [2024-03-16 19:08:50] <[-TE-]-RoLex> "the pointer will not fit into DWORD on 64 bit and it will truncate the pointer" [2024-03-16 19:09:05] <[-TE-]-RoLex> start * [2024-03-16 19:09:11] <[-TE-]-RoLex> backwards * [2024-03-16 19:10:25] yeah but again it was a crashlogger issue and even it does something wrong then you don't get such error from libdwarf [2024-03-16 19:11:16] it will simply not find the address in the pdb and you get an empty crashlog, see one attached to the bug report [2024-03-16 19:15:24] what mingw-w64 crt version does your compler have? [2024-03-16 19:16:27] is it mingw-w64 at all and not stock mingw? [2024-03-16 19:19:07] <[-TE-]-RoLex> im not sure, not been working with mingw that much. i uses msys2/cygwin and their latest included packages containing mingw-w64 [2024-03-16 19:19:12] <[-TE-]-RoLex> how to lookup crt version ? [2024-03-16 19:20:15] it's a define MINGW_VERSION_MAJOR or something similar [2024-03-16 19:21:25] see the libdwarf config.h change there's a #ifdef based on that to decide if old or new *printf needed [2024-03-16 19:22:26] <[-TE-]-RoLex> yes, i understand what you mean, will look up soon [2024-03-16 19:29:30] <[-TE-]-RoLex> first, before i forget, getDebugInfo(.. DWORD_PRT addr ..) will further be used in libdwarf calls and even compared to types such as Dwarf_Addr [2024-03-16 19:30:33] <[-TE-]-RoLex> this was a comment for myself to get back to. now back to MINGW_VERSION_MAJOR .. [2024-03-16 19:34:13] and also make sure your libdwarf folder is clean, you use the same files as in the DC++ repo, with poy's patches applied [2024-03-16 19:36:58] <[-TE-]-RoLex> yes, libdwarf folder is green according to WinMerge =) [2024-03-16 19:41:39] <[-TE-]-RoLex> MinGW-w64 version 12.0.0 int main () { printf("MinGW-w64 version %i.%i.%i\n", __MINGW64_VERSION_MAJOR, __MINGW64_VERSION_MINOR, __MINGW64_VERSION_BUGFIX); return 0; } [2024-03-16 19:43:14] that's pretty new [2024-03-16 19:43:36] the latest probably [2024-03-16 19:43:58] I've never compiled DC++ with a version this new [2024-03-16 19:44:29] <[-TE-]-RoLex> lets look in changelog [2024-03-16 19:44:32] I think the official one has 10 but compile.txt tells you [2024-03-16 19:44:59] its in nixman's builds' filename [2024-03-16 19:45:48] anyway this version definitely needs the new printf behavior to be set [2024-03-16 19:48:34] <[-TE-]-RoLex> yes, so libdwarf config is correct [2024-03-16 19:53:50] good luck bb tomorrow [2024-03-16 20:00:23] <[-TE-]-RoLex> thanks [2024-03-16 20:06:18] <[-TE-]-RoLex> GCC 12 Release Series > "STABS: Support for emitting the STABS debugging format is deprecated and will be removed in the next release. All ports now default to emit DWARF (version 2 or later) debugging info or are obsoleted." [2024-03-16 21:06:04] <[-TE-]-RoLex> https://gcc.gnu.org/onlinedocs/gcc-12.1.0/gcc/Debugging-Options.html < testing all options possible. this will take a few year, just so you know :-D [2024-03-16 22:24:42] <[-TE-]-RoLex> hmm .. if we get back to step 1, what do we get > Failed to load the debugging data into memory (error: 2) > ImageLoad > https://learn.microsoft.com/en-us/windows/win32/api/imagehlp/nf-imagehlp-imageload > fprintf(f, "getDebugInfo(path) = %s", path); // todo: test only > FearDC-stripped: getDebugInfo(path) =  Э’getDebugInfo(addr) = 1077810814lgetDebugInfo(path2) =  Э’[Failed to load the debugging data into memory (error: 2)] ? [2024-03-16 22:28:46] <[-TE-]-RoLex> sorry, my mistake > FearDC-stripped: getDebugInfo(path) = C:\Users\hundr\Downloads\dcpp\FearDC-stripped.exegetDebugInfo(addr) = 1077810398lgetDebugInfo(path2) = C:\Users\hundr\Downloads\dcpp\FearDC-stripped.pdb[Failed to load the debugging data into memory (error: 2)] ? [2024-03-16 22:52:48] hmm [2024-03-16 23:11:17] <[-TE-]-RoLex> im really going down to it, it doesnt take much time to compile CrashLogger.cpp alone. only need to place corrent print at right place =) [2024-03-16 23:11:39] <[-TE-]-RoLex> i will test everyhting [2024-03-17 07:57:15] well step 0 would be to know at last whether it's the pdb file or the processing code is wrong [2024-03-18 17:55:56] <[-TE-]-RoLex> so far so good upgrading libdwarf to latest version > FearDC: C:/MSys64/home/hundr/feardc/dwt/src/Taskbar.cpp (186:25), function: void/unknown setOverlayIcon(Taskbar* const this, ContainerPtr tab, IconPtr const& icon, tstring const& description) shows exact info needed. now only need to fix the following order :-D [2024-03-18 17:58:09] <[-TE-]-RoLex> seems like there is some kind of line rearrangement in dwarf5 [2024-03-18 17:59:54] so the msys toolchain cannot be convinced tp produce dwarf 4 format, evne though specified? [2024-03-18 18:00:29] <[-TE-]-RoLex> yes, they dropped some parts of older formats completely. binutils specifically [2024-03-18 18:00:34] <[-TE-]-RoLex> i only dont know which parts [2024-03-18 18:01:17] <[-TE-]-RoLex> as says by gcc 12 docs, dwarf5 id default now [2024-03-18 18:01:23] <[-TE-]-RoLex> id = is * [2024-03-18 18:02:04] it's the default in even gcc 9 I believe [2024-03-18 18:02:25] <[-TE-]-RoLex> maybe toolchain itself does the job it should, but binutils dont follow those standards anymore [2024-03-18 18:02:38] but good to know, maybe sometime Windows toolchains decide to do similar drop of older format versions [2024-03-18 18:03:24] <[-TE-]-RoLex> so it will be a future issue for dc++ aswell. ill fix the line order somehow, right now only last call it displayed. then i will merge my code so you can play with it too [2024-03-18 18:03:38] any significant change needed to uodate libdwarf? [2024-03-18 18:04:01] in crashlogger, I mean [2024-03-18 18:04:59] <[-TE-]-RoLex> rewriting crashlogger dwarf code, function names upgraded to *_b and *_c, plus some extra arguments. otherwise no. about 15 short changes in total [2024-03-18 18:06:00] good [2024-03-18 18:08:38] <[-TE-]-RoLex> oh, i didnt apply the dcpp patch for libdwarf yet, maybe thats the case on line order .. lets see [2024-03-18 19:42:59] <[-TE-]-RoLex> lol. bad news, this line was not even dwafp parsed line :-D [2024-03-18 19:46:05] <[-TE-]-RoLex> dwarf * [2024-03-18 19:46:57] <[-TE-]-RoLex> this is the internal imagehelp pdb read fallback method [2024-03-18 19:47:09] <[-TE-]-RoLex> .. on stripped exe with loaded pdb [2024-03-18 19:47:46] <[-TE-]-RoLex> the debug line description was 100% precice [2024-03-18 19:48:10] <[-TE-]-RoLex> hmm. i wonder if windows can read this dwarf format [2024-03-18 19:48:31] <[-TE-]-RoLex> or maybe windows can only generate last address after each call [2024-03-18 19:48:33] <[-TE-]-RoLex> dunno [2024-03-18 19:49:03] mmm [2024-03-18 19:51:19] <[-TE-]-RoLex> even info from current line. thats why there is only one line [2024-03-19 20:07:48] <[-TE-]-RoLex> im pausing with this crap for a while. too much headache :-D [2024-03-19 20:08:19] <[-TE-]-RoLex> should i upload the files i rewritten so far? so anyone else can look at it [2024-03-19 21:05:18] if you want [2024-03-19 21:05:29] it never hurts at least [2024-03-25 14:38:20] morning