#eulora Logs for 17 Jan 2017



January 17th, 2017 by Diana Coman
danielpbarron: diana_coman, why is it that I cannot add a csString or pawsSlot type to the CraftActivity class without it crashing? [11:32]
danielpbarron: there is already a csString variable defined in there.. and if i try to add a bool it works [11:33]
diana_coman: it's not the adding them that crashes, but something else you do [11:33]
danielpbarron: i commmented out everything else [11:33]
danielpbarron: it's literally just adding it in the botactivity.h file that causes the malloc [11:33]
danielpbarron: i tried doing csString thisisatest; [11:34]
danielpbarron: which is not mentioned anywhere else, and it causes it to crash after the login screen [11:34]
diana_coman: and what was the stack? [11:34]
diana_coman: what you say does not follow really; however, I can't say what you are doing there [11:35]
diana_coman: bbl [11:35]
danielpbarron: i'm adding a variable in CraftActivity in botactivity.h in the private section [11:36]
danielpbarron: there is already a csString logText; [11:37]
danielpbarron: but if i add anything else, like csString toolName; it crashes [11:37]
danielpbarron: http://wotpaste.cascadianhacker.com/pastes/VU0dP/?raw=true [11:38]
danielpbarron: the stack ^ [11:38]
danielpbarron: i hope that when i figure this out it will at least illuminate something about c++ ; right now the problem is incomprehensible to me [11:40]
danielpbarron: i was able to add bool needToReplaceTool; in the same spot [11:41]
danielpbarron: it's specifically csString and pawsSlot (and perhaps other types) that don't work [11:41]
danielpbarron: not that it matters, but i'm trying to get the craft bot to replace tool when it gets worn out [11:47]
danielpbarron: because i have lots of single use chairs for head [11:47]
mircea_popescu: danielpbarron sounds like the structure is allocated bitwise somewhere maybe [11:52]
mircea_popescu: does it have a constructor or anything ? [11:52]
danielpbarron: i don't know what that means [11:54]
mircea_popescu: (that'd explain why bool works, it's 1 bit, but string doesn't. something like the structure is say 1020 bits, gets bit-alligned to 1024 so you can squeeze another bit in there but not 8 for a char. this isn't the proper way to go about allocation though, so look where the structure is allocated in the first place, and make it size correctly) [11:54]
mircea_popescu: a "constructor" is a part of an object that deals with the object being instantiated. doing such things as allocating memory for it. [11:54]
danielpbarron: DoInit() i guess [11:55]
mircea_popescu: ok, and how does doinit allocate memory for your struct ? [11:55]
mircea_popescu: does it have a magic number or such ? [11:55]
danielpbarron: not in DoInit() [11:56]
mircea_popescu: hm. well it's allocated ~somewhere~. [11:57]
danielpbarron: seems to me that all the allocation happens outside of foxybot :/ [12:14]
mircea_popescu: hm [12:32]
diana_coman: csString is a crystal space data type [12:39]
diana_coman: same with the paws thing [12:39]
diana_coman: so no, not in DoInit() (which is just a method of CraftActivity [12:40]
mircea_popescu: then if you modify csstring it'd crash because well, it doesn't fit anything anymore [12:41]
diana_coman: that method happens to initialize stuff for CraftActivity but it's not a constructor [12:41]
mircea_popescu: i'm surprised the compiler even allows irt [12:41]
diana_coman: danielpbarron, give a paste of the whole botactivity.h that causes your crash (if you changed other files between no-crash/crash, paste those too) [12:46]
diana_coman: and oh, danielpbarron you are probably declaring it without initializing it, aren't you [12:47]
diana_coman: hence the crash, yeah [12:47]
diana_coman: look in botactivity.cpp , there is the constructor of each class, such as CraftActivity::CraftActivity() in your case [12:47]
diana_coman: you will notice that in the constructor (which is the bit that actually creates an object of that class) how to initialize a csString if you want to use that [12:49]
diana_coman: the other thing I suspect is that you give them a name that masks something else and then it crashes because it ends up trying to use something that is not initialized [12:51]
diana_coman: danielpbarron, the stack basically says that some memory allocation/deallocation is wrong but I can't tell from there what causes it as such [13:02]
jurov: " ~csStringFast (this=0x0 " << basically something tries to deallocate null pointer [13:06]
jurov: but to say what, where, needs to analyze teh codez [13:07]
Framedragger: maybe the destructor of that class is such that it calls destructor of every object in that class - and the new danielpbarron logText is only declared, but never initialized (and hence remains null until attempted object destruction)? just speculatin' [13:11]
danielpbarron: i tried it with a variable name that certainly wasn't already used, still crashed [13:11]
Framedragger: danielpbarron: but maybe also try to initialize it in corresponding .c? [13:11]
danielpbarron: and i can put a bool in there without ever initializing [13:11]
Framedragger: as of now it's only in .h (only declaration) right [13:12]
Framedragger: csString is a struct, not a built-in type, so maybe different behaviour. that being said, probably a long shot... [13:12]
danielpbarron: plus it crashes even if i initialize [13:12]
Framedragger: ah :/ [13:12]
danielpbarron: i think mircea_popescu has it, or at least his theory is what i was thinking before i raised the question here [13:13]
jurov: but the stacktrace does not show aby bot code, but instead some xml parsing [13:13]
mircea_popescu: Framedragger may have a good lead too. [13:14]
jurov: since stack is corrupted, might be spurious, ofc [13:14]
mircea_popescu: since otherwise most deref null pointers are caught as such by compiler. [13:14]
diana_coman: danielpbarron, basic types such as bool are fixed-size and not dynamically allocated hence no chance to crash, yeah [13:19]
diana_coman: csString despite looking perhaps like a basic type, is not one [13:20]
diana_coman: the stack shows that the whole thing happens inside crystal space stuff (btw you CAN look at that too), but that's not much help really [13:20]
diana_coman: and the crash WILL happen at the time you notice it simply because at that point the client creates all stuff including the bot , hence the activities etc [13:21]
diana_coman: but that's not much help [13:21]
jurov: best to recompile with debug info and run under gdb [13:22]
danielpbarron: how? [13:22]
diana_coman: danielpbarron, out of curiosity: do you initialize that csString in DoInit? [13:22]
diana_coman: because I suspect that is what is going wrong [13:22]
jurov: tries to remember [13:23]
diana_coman: basically when you say there csString blabla; you just *declare* that thing [13:23]
danielpbarron: it crashed when i let it initialize in DoInit [13:23]
diana_coman: how do you let it initialize in DoInit? [13:24]
danielpbarron: toolName = csString(""); [13:24]
jurov: ahh it's configure --enable-debug . Best to enable debug and recompile CS, too. [13:24]
jurov: danielpbarron since it's in xml parser, check your xml files in data dir & ~/.Eulora . It can happen they get corrupted when it crashes. [13:26]
diana_coman: myeah, might even simply be calling for a full recompile [13:26]
danielpbarron: .. [13:26]
jurov: diana_coman: perhaps you can enable debugging by default in released source, to make life a bit easier [13:28]
diana_coman: xml is the widget definition too, which would be for the foxybot (as it has a window- widget) [13:28]
diana_coman: the client creates the widgets including foxybot; foxybot in turn creates one object of each activity type and so it gets there [13:29]
diana_coman: danielpbarron, if you compiled only partially between crashes, god knows what's in there [13:30]
diana_coman: crashes and changes of code I should say [13:31]
diana_coman: ftr and separate I'd rather stay away from crystal space stuff if not absolutely needed - when I made foxybot I didn't quite know crystal space, but meanwhile I got to know it better [13:32]
diana_coman: danielpbarron, got to the bottom of it? [14:49]
danielpbarron: nope [14:51]
diana_coman: if full clean compile and same trouble, one needs to see the code to say anything [14:52]
diana_coman: hello Canaimero-e64b [15:42]
shinohai: I liked the e63a model better, but welcome anyway. [15:42]
diana_coman: lol; can't quite figure out what they do exactly [15:51]
diana_coman: danielpbarron, ftr: I added a csString danieltest; where you said (in botactivity.h as private member of CraftActivity) and it runs perfectly fine of course [16:01]
danielpbarron: lol great [16:02]
diana_coman: as said initially: http://logs.minigame.bz/2017-01-17.log.html#t16:33:38 [16:05]
lobbesbot: Title: #Eulora log for Tuesday, 2017-01-17 (at logs.minigame.bz) [16:05]
danielpbarron: yours runs with just that change? you didn't initialize it anywhere? [16:05]
danielpbarron: i just did jam -aq client and it still crashes [16:05]
danielpbarron: or what do you mean by "full clean compile" ? [16:06]
diana_coman: yep, just that change on the eulora client release version [16:09]
diana_coman: the -aq should do, yes; basically if it built everything from scratch it means a clean compile [16:10]
danielpbarron: why would adding a declaration like this cause it to crash? apparently some other change i made that works without crashing on its own conflicts with this somehow [16:18]
diana_coman: it should not make it crash, that's exactly the thing; what you declare there is an object not a pointer, no real reason to crash [16:18]
diana_coman: it's more likely that this change highlights trouble you introduced earlier but somehow did not manifest at that time [16:19]
diana_coman: and being memory related, it's quite impossible to tell without seeing the code [16:20]
diana_coman: possibly some changes you made to craftactivity access unallocated memory that then becomes overwritten by this new addition - it could have been by whatever other random thing; or something of this type [16:22]
danielpbarron: how would i access unallocated memory? [16:29]
danielpbarron: the other changes i made to craftactivity are commented out for now [16:32]
diana_coman: for instance if some of your code writes out of bounds [16:32]
danielpbarron: what does that mean? [16:32]
diana_coman: danielpbarron> the other changes i made to craftactivity are commented out for now <- this means your troublesome change is *somewhere* else [16:32]
danielpbarron: i also changed a function in worldhandler called GetEquippedToolName [16:33]
danielpbarron: so that it checks more than just the hand [16:33]
diana_coman: danielpbarron> what does that mean? <- say you allocate 4 bytes for a char* pointer; the pointer is simply an address so it means that you can then write starting at that address 4 bytes that nobody else will touch [16:34]
diana_coman: if you however then go and write 5 bytes at that address [16:34]
diana_coman: the 5th is basically writing out of bounds [16:34]
diana_coman: I suppose if you want to see it for yourself the most straightforward thing is to get the release version and simply add that declaration there; compile and run [16:35]
diana_coman: line 391 of botactivity.h , right under csString logText; [16:35]
danielpbarron: see what for myself? [16:43]
danielpbarron: i believe you that it should work [16:43]
danielpbarron: i don't know how big the things are that i'm storing or how much was too big. or where it was defined what is too big [16:44]
diana_coman: basically that's the crux of it: you are storing somewhere something bigger than you allocated memory for [16:45]
diana_coman: I suppose you can slowly go the other way and only gradually add back the changes you made to catch the problem [16:46]
danielpbarron: they depend on this thing that won't work [16:47]
diana_coman: as in: start with the release version, unmodified; add the csString thing; compile; add then your changes one by one , compiling at each step [16:47]
danielpbarron: ah, yes that i will eventually have to do if i can't get it otherwise [16:47]
danielpbarron: was hoping to avoid that [16:47]
danielpbarron: i just commented out the worldhandler changes and it still crashes so i guess the problem is in my explore changes [16:48]
diana_coman: I understand you want the item equipped on head or whatever: make another method there in WorldHandler either with slot given as parameter or otherwise specifically for the head slot [16:48]
danielpbarron: yeah i'll do that too [16:48]
danielpbarron: if i do something like lastPos = currPos , is that making a copy of currPos and storing it in lastPos ? or is it making currPos and lastPos 'point' to the same 'object' ? [17:45]
mircea_popescu: pointers point, they don't store anything. [17:45]
danielpbarron: fffffff [17:45]
mircea_popescu: that's why the whole allocation dance. [17:45]
danielpbarron: well if i say x = 2 that's storing 2 in x right? or is it saying that x 'points' to the number 2? [17:46]
mircea_popescu: depends if x is an int or a pointer. [17:46]
mircea_popescu: that's the meaning of trhe comment above, "bool is a fixed size" [17:46]
diana_coman: danielpbarron, pointers store an address [17:47]
danielpbarron: so then there must be a copy vector function? [17:47]
diana_coman: int* x means that at x you store the address at which you'll find an int [17:47]
mircea_popescu: the machine keeps a heap and a stack, the fixed size data (ints etc) go on the stack, the dynamically allocated (ie, pointed to) data goes on heap [17:47]
diana_coman: int x means on the other hand that you store a int value [17:47]
diana_coman: what are lastPos and currPos? how are they defined? [17:48]
mircea_popescu: they sound like 3 int constructs to me [17:48]
mircea_popescu: (x y z) [17:48]
danielpbarron: currPos is worldHandler::GetCurrentPos() [17:48]
diana_coman: ah, the location [17:48]
diana_coman: lemme look [17:48]
danielpbarron: and it was already in there apparently [17:48]
danielpbarron: lastPos is something i added [17:49]
diana_coman: csVector3 type you mean danielpbarron ? [17:49]
mircea_popescu: yes but what type is it is al lthat matters. [17:49]
danielpbarron: i'll just set it the same way currPos gets set for now [17:49]
danielpbarron: diana_coman, yeah [17:49]
diana_coman: but I don't see the lastPos you are talking about [17:50]
danielpbarron: i added it [17:50]
diana_coman: because it matters if it is csVector3 or csVector3* or &csVector3 [17:50]
danielpbarron: i did whatever currPos is [17:50]
diana_coman: yeah, but what did you do with it and *where* [17:50]
diana_coman: each variable has a lifetime basically [17:50]
danielpbarron: store currPos in it [17:50]
diana_coman: if you have csVector3 x, y; you can say x = y; and it will copy the three values of y into x; that works because csVector3 defines "=" to do that basically [17:52]
diana_coman: you can see examples of that done throughout botactivity.cpp [17:53]
danielpbarron: currPos and lastPos are both csVector3 [17:53]
danielpbarron: ok so then that wasn't the problem then? [17:53]
danielpbarron: i had that change in there a while and the explore bot was working exactly as i expected it to [17:54]
birdman: hanbot can i buy a stack of lbn at the price you quoted me a few days ago? [17:55]
birdman: oh and that good hammer too [18:03]
diana_coman: danielpbarron, from what you say that seems ok; the moment you declare csVector3 currPos; that is already allocated basically as 3*sizeof(float) or whatever the three coordinates are [18:04]
danielpbarron: no way! i'm in somehow! [18:52]
danielpbarron: lemme see if i can figure out how i fixed it [18:53]
mircea_popescu: wd [18:56]
danielpbarron: it may have been that i had declared lastPos as 'protected' rather than 'private' [19:04]
jurov: that's unlikely [19:12]
danielpbarron: it works! [21:30]
mircea_popescu: win. [21:37]
DicePower: Heya :) [22:40]
mircea_popescu: how goes [22:41]
DicePower: Pretty good, how has everything been? [22:41]
mircea_popescu: great really [22:41]
DicePower: awesome :D [22:42]
DicePower: Any new developments with Eulora? [22:42]
DicePower: I've been away for like half a year or something. [22:43]
mircea_popescu: ah, seen the latest auction ? [22:44]
DicePower: Nope [22:44]
DicePower: You may recall that I never actually started the game. :D [22:44]
mircea_popescu: http://www.contravex.com/2017/01/16/a-humble-auctioneer-and-his-record-setting-first-auction/ [22:44]
mircea_popescu: well then lol. various changes but not anything you'd notice right ? [22:45]
DicePower: true [22:45]
DicePower: I was trying to automate character creation to figure out the range of stats. [22:46]
mircea_popescu: i recall [22:46]
mircea_popescu: i guess then you're in a prime position to say if anything changed huh. [22:46]
DicePower: I ended up working on too many things at once and kinda put Eulora on the back burner. [22:46]
mircea_popescu: anything good ? [22:47]
DicePower: Just some things for other games. Nothing terribly impressive. [22:48]
mircea_popescu: ah [22:48]
mircea_popescu: oh and you missed on the hackathon too huh [22:48]
DicePower: Oh? [22:49]
mircea_popescu: http://trilema.com/first-eulora-hackathon [22:49]
lobbesbot: Title: First Eulora Hackathon on Trilema - A blog by Mircea Popescu. (at trilema.com) [22:49]
DicePower: Oh, that's looks cool [22:50]
mircea_popescu: was a while back though. [22:51]
DicePower: I'm looking forward to returning to Eulora now and finishing my program, and finally starting the game :P [22:53]
DicePower: IIRC I had completely automated the login process except for one click. [22:53]
DicePower: I think it was the final click on the character creation screen. [22:53]
mircea_popescu: shouldn't be too hard, just read the client and modify it. [22:55]
DicePower: Yeah, I know I'd worked my way through most of it. [22:56]
DicePower: There was just one tricky part somewhere. [22:56]
mircea_popescu: aite. [22:57]
DicePower: And now my client is out of date, so I probably have to go through the whole process again :D [22:58]
mircea_popescu: you got 0.1.2b ? [22:59]
DicePower: 0.1.1 [23:00]
mircea_popescu: aha yeah [23:01]
DicePower: Unless the version check is just client side like the character name requirements were [23:02]
mircea_popescu: you might be able to patch it into working. [23:03]
DicePower: Not looking good [23:17]
DicePower: I guess I'll be starting from scratch then :D [23:18]
whaack: I'm having a few issues with my game client. On the character creation screen the buttons to change features don't work (they just get pressed but nothing happens) When the game loads there seems to be some graphic issues - in the termianl I get "Could not load image 'generic_water_001_ant' and the water in game consequently looks wrong. I'm on ubuntu 14.04 [23:19]
DicePower: The first is intended. [23:20]
mircea_popescu: whaack the buttons don't do anything and the water thing is suspicious [23:20]
mircea_popescu: whaack if wrong is "black", atm it's night so that's right. [23:20]
mircea_popescu: which one of you is xaren ? [23:22]
whaack: me [23:22]
mircea_popescu: come meet me in town ima give you some stuff. [23:22]
whaack: https://postimg.org/image/seyift4vd/ that's my water, also it seems like objects only render when they're pretty close i'm not sure if this is intended/normal [23:23]
lobbesbot: Title: eulorawater â\u0080\u0094 Postimage.org (at postimg.org) [23:23]
mircea_popescu: whoa artefactcity [23:23]
mircea_popescu: whaack that's not right but i can't readily tell you what the problem is there. [23:24]
DicePower: Your hardware isn't super old by any chance, is it? [23:25]
whaack: nah [23:26]
whaack: mircea I'm at a place with 3 buildings and a campfire, when i walk into a gate i see a load screen and then a room with a ghost. Is this the town? [23:29]
mircea_popescu: nah [23:34]
mircea_popescu: town is up the hill from the boat place. [23:34]
mircea_popescu: $~town [23:34]
mircea_popescu: hm what was it [23:34]
mircea_popescu: !~eu.town [23:35]
jhvh1: Town is located @ 176, 56, 161 [23:35]
mircea_popescu: anyway, i'm about to call it a night, so if you don't make it tonight then tomorrow. [23:35]
whaack: kk, how do you check coords? [23:37]
mircea_popescu: /pos [23:37]
mircea_popescu: also /pilot will point you the rifght way [23:37]
mircea_popescu: aha there you are [23:41]
mircea_popescu: trade me whaack [23:41]
mircea_popescu: enjoy! [23:43]
whaack: lovely [23:43]
whaack: ty [23:43]
mircea_popescu: and incidentally -- i think he has a good point. we'll prolly move heina first, and then next wed electron too by the fire next to the buildings. [23:43]

Comments feed: RSS 2.0

Leave a Reply