Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[walberg]

I don't see that a 0.34.06 compatible release has been officially announced yet, so probably everything since 0.34.05-r1 is still considered unstable, but I wanted to report an apparent bug anyway...

On all commits since edf77c (Link protobuf to dfhack core as a shared library.), the Linux build seems to no longer work. It compiles fine, but running it simply gives "Memory fault" and dies. I did a Debug build, and the core file generated indicates the memory fault is here:

(snip)

Not so sure that helps a lot, but it gives someplace to start. This is on a 64-bit Debian 5.0.8 system with GCC 4.5.0, but is repeatable on Debian 6.0.4 (64-bit also with same version of compiler). I could try a different compiler version as well, but it'll take a while to cook one up...

Latest code (d2d16271f0) is working fine for me, built with GCC 4.5.3 on 64-bit Gentoo. Remember that you need to compile dfhack as a 32-bit app. Try:

Code: [Select]

cd dfhack/build
setarch i386 cmake .. -DCMAKE_BUILD_TYPE:string=Release -DCMAKE_INSTALL_PREFIX=~/df_linux
setarch i386 make install


It's not related to setarch (or gcc -m32 for that matter). I'm starting to think it's due to a library mismatch or something. I've tried gcc-4.5.0, gcc-4.5.3 and gcc-4.7.0 all with the same results. Running 'dfhack -g', I can get a little more info:

Spoiler (click to show/hide)

(gdb) run
Starting program: /usr/local/games/dwarf-fortress/dfbin/libs/Dwarf_Fortress
ERROR: ld.so: object './hack/libdfhack.so' from LD_PRELOAD cannot be preloaded: ignored.
ERROR: ld.so: object './hack/libdfhack.so' from LD_PRELOAD cannot be preloaded: ignored.
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 0xf435f6e0 (LWP 22329)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xf435f6e0 (LWP 22329)]
0xf7573038 in global constructors keyed to DataStaticsFields.cpp () from ./hack/libdfhack.so
Current language:  auto; currently c++
(gdb) where
#0  0xf7573038 in global constructors keyed to DataStaticsFields.cpp () from ./hack/libdfhack.so
#1  0xf76b391d in __do_global_ctors_aux () from ./hack/libdfhack.so
#2  0xf75012d8 in _init () from ./hack/libdfhack.so
#3  0xf77b76a5 in ?? () from /lib/ld-linux.so.2
#4  0x00000001 in ?? ()
#5  0xffe2ab94 in ?? ()
#6  0xffe2ab9c in ?? ()
#7  0x0804c990 in ?? ()
#8  0xf77c390b in ?? () from /lib/ld-linux.so.2
#9  0xffe2ab94 in ?? ()
#10 0x00000001 in ?? ()
#11 0xf77c6668 in _r_debug ()
#12 0x00000000 in ?? ()

[...........]
0xf7573004 <_GLOBAL__I_DataStaticsFields.cpp+3424>:       lea    0x37968(%ebx),%eax
0xf757300a <_GLOBAL__I_DataStaticsFields.cpp+3430>:       mov    %eax,(%esp)
0xf757300d <_GLOBAL__I_DataStaticsFields.cpp+3433>:       call   0xf750449c <__cxa_guard_release@plt>
0xf7573012 <_GLOBAL__I_DataStaticsFields.cpp+3438>:       cmpb   $0x0,0x37970(%ebx)
0xf7573019 <_GLOBAL__I_DataStaticsFields.cpp+3445>:       jne    0xf757305e <_GLOBAL__I_DataStaticsFields.cpp+3514>
0xf757301b <_GLOBAL__I_DataStaticsFields.cpp+3447>:       lea    0x37970(%ebx),%eax
0xf7573021 <_GLOBAL__I_DataStaticsFields.cpp+3453>:       mov    %eax,(%esp)
0xf7573024 <_GLOBAL__I_DataStaticsFields.cpp+3456>:       call   0xf750a6ac <__cxa_guard_acquire@plt>
0xf7573029 <_GLOBAL__I_DataStaticsFields.cpp+3461>:       test   %eax,%eax
0xf757302b <_GLOBAL__I_DataStaticsFields.cpp+3463>:       je     0xf757305e <_GLOBAL__I_DataStaticsFields.cpp+3514>
0xf757302d <_GLOBAL__I_DataStaticsFields.cpp+3465>:       mov    0x37998(%ebx),%eax
0xf7573033 <_GLOBAL__I_DataStaticsFields.cpp+3471>:       mov    (%eax),%edx
0xf7573035 <_GLOBAL__I_DataStaticsFields.cpp+3473>:       mov    %eax,(%esp)
0xf7573038 <_GLOBAL__I_DataStaticsFields.cpp+3476>:       call   *0x18(%edx)
0xf757303b <_GLOBAL__I_DataStaticsFields.cpp+3479>:       mov    $0x0,%edx
0xf7573040 <_GLOBAL__I_DataStaticsFields.cpp+3484>:       cmp    $0x8,%eax
0xf7573043 <_GLOBAL__I_DataStaticsFields.cpp+3487>:       cmove  0x37998(%ebx),%edx
0xf757304a <_GLOBAL__I_DataStaticsFields.cpp+3494>:       mov    %edx,0x37994(%ebx)
0xf7573050 <_GLOBAL__I_DataStaticsFields.cpp+3500>:       lea    0x37970(%ebx),%eax
0xf7573056 <_GLOBAL__I_DataStaticsFields.cpp+3506>:       mov    %eax,(%esp)
0xf7573059 <_GLOBAL__I_DataStaticsFields.cpp+3509>:       call   0xf750449c <__cxa_guard_release@plt>
[...........]


(gdb) info registers
eax            0xf77891a0       -143093344
ecx            0x804c428       134530088
edx            0x0       0
ebx            0xf7768820       -143226848
esp            0xffe2aa80       0xffe2aa80
ebp            0xffe2ab08       0xffe2ab08
esi            0xf751bee0       -145637664
edi            0xf751be00       -145637888
eip            0xf7573038       0xf7573038 <global constructors keyed to DataStaticsFields.cpp+3476>
eflags         0x10202       [ IF RF ]
cs             0x23       35
ss             0x2b       43
ds             0x2b       43
es             0x2b       43
fs             0x0       0
gs             0x63       99

Part-way through the global constructor routine, it's attempting to make an indirect call (probably through a vtable or some such), but the base address in %edx is 0. Must be a missing NULL check somewhere.

Unfortunately, there isn't an easy way that I know of to correlate that global constructor code back to an actual source code line number... And due to the fact that pretty much that entire source file is generated by the build process anyway, the culprit isn't readily obvious.

[robertheinrich]

I suggest you guys (desperately trying to build the linux version, mainly) just wait a short while longer. New release is imminent. Also it seems that the linux version needs to be built with gcc 4.4 by the way.

[ag]

Part-way through the global constructor routine, it's attempting to make an indirect call (probably through a vtable or some such), but the base address in %edx is 0. Must be a missing NULL check somewhere.

Just debugged that in the chat. It was me screwing up static initialization discipline - it was trying to access an object that was not guaranteed to be initialized yet ^^; Since this is undefined behavior, it apparently depended on something like the standard library version.

[notfood]

Works fine under Linux, I tested most tools.

DFHack 0.34.05-r1-232-g1f5c586
Archlinux
gcc-multilib 4.6.3-1

I had to remove the libs/libstdc++.so.6 from the df_linux folder for it to run properly, otherwise it complained about lack of Strings.

[peterix]

Alright, finally got this out of the gate

Check the first post for the news and download links. The new stonesense features alone are awesome, but there's a whole lot more of new stuff too.

Oh, and we have DFusion working on Windows again. The linux version actually runs, but some of the more involved things it does don't, so I haven't included it in the linux build yet.

[vjek]

Nice, well done!  /applaud /cheer

[khearn]

in game version of vdig would be different, it would only auto-designate the surrounding tiles if in the same vein, not reveal the whole vein directly. it is no different from what happens today, only we have to do it manually after each new tile is revealed.

A problem with auto-digging veins is that it can happen that you expose your fortress to danger (by creating an unwanted hole which leads to the surface or maybe even magma/water). And you can also destroy existing rooms, engraved walls (if masterpieces that will make the engraver sad) and whatnot. So I guess Toady's version would have to take all this into consideration.

Yeah, just like the building code takes into account whether or not the dwarf will be trapped. Or the channeling code takes into account whether or not it will cause a cave in. Or the removing construction code...

I suspect your dwarves will blithely follow a vein until they open a hole to let a siege in or flood the fortress. Why should they suddenly start being any more intelligent?

[Korva]

Thanks a bunch for the update. I have a hard time playing without reveal and prospect to see if an embark spot is really worthwhile, and clean map is a lifesaver too.

[orius]

Alright, finally got this out of the gate

Check the first post for the news and download links. The new stonesense features alone are awesome, but there's a whole lot more of new stuff too.

Oh, and we have DFusion working on Windows again. The linux version actually runs, but some of the more involved things it does don't, so I haven't included it in the linux build yet.

Hah, a few hours after I download one of the temp fixes for 34.06.  Well at least there's some good new stuff to play with too.

[tahujdt]

Yay, finally DFusion! I'm looking forward to changing my conglomerate to candy as well.

[NecroRebel]

I've encountered what might be a bug with vdig. I used it to designate veins of several materials, including limonite, hematite, and lignite, but the autodesignation process appeared to get interrupted by the presence of small clusters of various gems next to the veins, even when the desired vein material was itself continuous. Using vdig on these interruptions designated the desired material on the interrupting spots themselves and also the gems that were part of the small cluster. It appears that the material generation process scattered the small clusters, then drew the veins on top of them, but where the veins intercepted small clusters the program still considers to be the overwritten small cluster material. This may be a problem with vdig or with DF itself.

[Rumrusher]

Yay, finally DFusion! I'm looking forward to changing my conglomerate to candy as well.

you might want to add this code into dfusion's tools/init file because empregnate can't be use well in adventure mode as is.

Spoiler (click to show/hide)

Code: [Select]

function tools.advempregnate(unit)--for adventure mode
if unit==nil then
unit=getCreatureAtPos(getxyz()) end

if unit==nil then
error("Failed to empregnate. Unit not selected/valid")
end
if unit.curse then
unit.curse.add_tags2.STERILE=false
end
local arr1=unit.appearance.unk_51c
local arr2=unit.appearance.unk_51c
local created=false
if unit.relations.pregnancy_ptr == nil then
print("creating preg ptr.")
if false then
print(string.format("%x %x",df.sizeof(unit.relations:_field("pregnancy_ptr"))))
return
end
local size,offset=df.sizeof(unit.relations:_field("pregnancy_ptr"))
local s1=df.sizeof(arr1)
local s2=df.sizeof(arr2)
engine.poked(offset,engine.alloc(s1+s2))
created=true
end
local tarr1=unit.relations.pregnancy_ptr.anon_1
local tarr2=unit.relations.pregnancy_ptr.anon_2
if created or #tarr1~= #arr1 then
print(string.format("Before: %d vs %d",#tarr1,#arr1))
print("Setting up arr1")
print(string.format("%x %x",df.sizeof(tarr1)))
--tarr1=arr1:new()
local size,offset=df.sizeof(tarr1)
engine.poked(offset,engine.alloc(#arr1))
engine.poked(offset+4,#arr1)
print(string.format("after: %d vs %d",#tarr1,#arr1))
end
if created or #tarr2~= #arr2 then
print("Setting up arr2")
--tarr2=arr2:new()
local size,offset=df.sizeof(tarr2)

engine.poked(offset,engine.alloc(#arr2*2))
engine.poked(offset+4,#arr2)
end
print("Setting preg timer.")
unit.relations.pregnancy_timer=10
unit.relations.pregnancy_mystery=1
end
tools.menu:add("Adv_Empregnate",tools.advempregnate)


[Girlinhat]

I never got into DFusion... why is it so good?

[slink]

I've encountered what might be a bug with vdig. I used it to designate veins of several materials, including limonite, hematite, and lignite, but the autodesignation process appeared to get interrupted by the presence of small clusters of various gems next to the veins, even when the desired vein material was itself continuous. Using vdig on these interruptions designated the desired material on the interrupting spots themselves and also the gems that were part of the small cluster. It appears that the material generation process scattered the small clusters, then drew the veins on top of them, but where the veins intercepted small clusters the program still considers to be the overwritten small cluster material. This may be a problem with vdig or with DF itself.

I have the same problem here.  Where veins of hematite crossed veins of tetrahedrite, vdig once diverted to the tetrahedrite and once did not.  It skipped occasional ore tiles even when they were of the correct type for the vein it was following.  It sometimes marked gems with the ore, and always marked any surrounding ore with gems.  When I tried to choose a small inclusion of turquoise for mining, it marked an entire surrounding area of kaolinite.  I never had crossing veins of ore with the previous versions of DFHack, but I know it could tell ore from gems before.

[Girlinhat]

I've had crossing veins before, and I haven't used the newest DFHack but that's definitely a new bug.