search

barzerman / barzer

barzer engine code
MIT License
2 stars 0 forks source link

MAJOR EMERGENCY: engine killer rule #618

Closed barzerman closed 11 years ago

barzerman commented 11 years ago

rule kills the engine http://eu.barzer.net/profile?rule_id=280631 when this is on the engine never restarts

barzerman commented 11 years ago

@0xd34df00d this reproduces: on sveta 

cd /home/yanis/crash/usr/share/barzer
/usr/share/barzer/barzer.exe -cfg site/alpha/1000195/config.xml

look at this ASAP

0xd34df00d commented 11 years ago

How do you restart internally?

barzerman commented 11 years ago

what restart internally? copy eu.barzer.net:/home/yanis/site.user_data.tar.bz2 somewhere then tar xvfj it and in current directory run with cmd line options: -cfg usr/share/barzer/site/alpha/1000195/config.xml -home usr/share/barzer/

On Wed, Aug 28, 2013 at 6:08 PM, Georg Rudoy notifications@github.comwrote:

How do you restart internally?

— Reply to this email directly or view it on GitHubhttps://github.com/barzerman/barzer/issues/618#issuecomment-23452138 .

www.barzer.net

barzerman commented 11 years ago

crash is in barzer_beni.cpp:185

barzerman commented 11 years ago 
182         const auto tokId = i->first.getTokId();
183         const auto str = m_universe.getGlobalPools().internalString_resolve(tokId);

tokId is 0xFFFFFFFF

barzerman commented 11 years ago

something is fucked up in the generation as well - this should never be possible

barzerman commented 11 years ago

@pltr - look in the fucking config file (in that same archive): 

   <entity class_name="bbuy" class_id="1000295">

still 295 vs 195 ... +100 bites back

barzerman commented 11 years ago

@0xd34df00d this teaches us about defensive coding and checking for NULL ...

barzerman commented 11 years ago

@pltr you need to look at this ASAP - i wanna know what happened - there seems to be a deeper prob lem in the generation

barzerman commented 11 years ago

@pltr never mind - it's not the generation issue - pure engine fuckup. @0xd34df00d - defensive coding, my friend ....

0xd34df00d commented 11 years ago

Ah crash, reproduces. I thought there were issues with the restarting sequence itself, not in starting barzer.

0xd34df00d commented 11 years ago

I think this is really about the reverse: if we checked for null and handled this more gracefully we could have this stuff ignored for quite some time.

Not everything should be defended. If the token fails to resolve it means we have things really fucked up and better fail fast.

0xd34df00d commented 11 years ago

Why have you closed the issue?

0xd34df00d commented 11 years ago

Also, fails to reproduce. I was too sleepy at the moment to mess issue in my tester with barzer's one. Nevermind.

Barzer starts perfectly for me from the 195 alone, ending with

BENI: 1536 names for 1000295:23
Done in 0.390568 seconds
barzerman commented 11 years ago

because i fixed it. there's an id-less mkent there in the killer rule mkent(123 20)

no id, so your code would resolve 0xFFFFFFFF and then crash it's fixed

barzerman commented 11 years ago

look at the commit and at the rule - grep 280631 , see the mkent 

<stmt n="280631" name="large" x=""><pat><any><t>large</t><t>largest</t><t>big</t><t>biggest</t></any></pat><tran><mkent c="1000295" s="27"/></tran></stmt>
0xd34df00d commented 11 years ago

Seems like wrapping main's body in try { doStuff (); } catch (...) {} and calling it "a fix".

0xd34df00d commented 11 years ago

I have the rule at hand, I don't have any checks merged from your master, but barzer doesn't crash.

You've just hid an issue somewhere else, and while the urge to fix such nasty shit is understandable, this is not really a solution and needs further investigation, my friend.

barzerman commented 11 years ago

not sure why you cant reproduce - it's fixed. look at commit that's if you don't really think about it. mkent(10 10) is legal this defensive stuff MUST be everywhere where user input is possible. Also, as an extra hint - the fact that auto was used masked the fact that it's const char* which led you to forget that it may be null (legitimately, like in this case or based on an invalid input)

0xd34df00d commented 11 years ago

What user input in addSubclassIds are you talking about? If the for condition hasn't fired yet, we're perfectly legit, or the issue is deeper again.

The fact that auto is used hides nothing from me. I've become used to languages without explicit type declarations quite some time ago.

barzerman commented 11 years ago

the user input is the rule which has a n id-less mkent in translation. This ends up producing a wildcard entity with class subclass and 0xFFFFFFFF for id . Feel free to look at it when youre less sleepy .

In general - if it returns const char* and the header file doesnt promise that 0 is never returned - check for NULL . it's a multiuser system .

0xd34df00d commented 11 years ago

Seems like a legit scenario. Ok, agreed then.

0xd34df00d commented 11 years ago

(I still wonder why barzer doesn't segfault for me though)