Something seems to be wrong with Series EV specifically. Can't find a way to reproduce it so far, as it seems random. Happens during battles, in build mode, and when just running around and not doing anything in particular. Level doesn't seem to matter.
Crash is near guaranteed if playing through a stage. Game is perfectly stable as Apprentice, Squire and Summoner.
Tried to get a backtrace, this results:
#0 0xf7354a60 in ?? () from /usr/lib/nvidia/libnvidia-glcore.so.304.64
Cannot access memory at address 0xb37334fc
Did some more testing after updating the nvidia driver to:
NVRM version: NVIDIA UNIX x86_64 Kernel Module 304.64 Tue Oct 30 10:58:20 PDT 2012
GCC version: gcc version 4.7.2 20120921 (Red Hat 4.7.2-2) (GCC)
Backtrace now says:
#0 0xf73549e0 in ?? () from /usr/lib/nvidia/libnvidia-glcore.so.304.64
Cannot access memory at address 0xbea0f7c8
In both attempts at Foundries and Forges it crashed during the first combat round. I've managed to make through it once before, but the testing so far indicates this takes a lot of luck. A stage so far is a lot more likely to crash than not.
Just adding that I'm having this problem too. Have been able to play through all the levels just fine on my monk (locally anyways) and i made it through the first level just fine. Ever since then I haven't been able to make it all the way through a level, though it seg faults at different points in the game, and after different amounts of time each time.
I'll play around with things in game to see if it's anything in particular that's triggering it, and maybe I'll be lucky enough to find a direct cause.
(In reply to comment #2)
Update:
Every time I think I've nailed down the bug it seems to change. I have noticed that it will crash just as much if EV's towers are up but I'm switched to a different hero (monk in this case), which leads me to believe it's an issue with a tower/s. However, in pursuit of this theory, I have played multiple levels with each of the three towers I have unlocked (proton, physical, reflection) by themselves without a single crash. I had one crash when I tried to place both a reflector and a physical beam but have been unable to reproduce it.
I feel compelled to note that recently, I have been experiencing this error less overall, and that the only related changes to my system (that I can think of anyways) are 1) I changed from the recommended NVidia driver to the 310 experimental one, and 2) I have gotten into the habit of overclocking my first processor (both changes for gw2). As a result, when I would pretty much start a level as EV, place a tower, and in no time get a seg fault, now it's more or less even playable.
So.... what all this means, I can't really say. Maybe someone else can find a thread in this, and, dare I hope, find a way to eliminate the seg faults all together. I still have a nagging suspicion that it's something with the reflection beam tower, but can't seem to prove it. Hope this is helpful to someone.
I have the same problem.
I can play the game for hours as the Monk class with no issues. Then I can fire up the Series EV and it may last 10 minutes, 30 minutes or 2 minutes - segfault.
Maybe there's some correlation to the proton beams? I've noticed (and this may be random chance) that when not using proton beams I don't experience crashes.
OK, well, not sure if this is where I should post this, but tried the linux steam version, and had the same issue. It does only seem to happen when beams are used, though the type seems irrelevant (leading me to believe it has something to do with shared beam code, like beam length?).
I'm also affected by this bug. (nvidia 313.26)
Since I think no one really pointed out yet: The crashes also happen, when you're not playing the EV yourself. Having someone else in your team who plays EV and places beams is enough to trigger the crashes. (Which means there's not really a workaround by just not playing EV. Whenever an EV joins your game, you're doomed)
Not really the best way to reproduce it, but I tried about 5-6 times to solo the very first level with the EV & the first 2 beams only and couldn't finish it once because of the crashes, which kinda gives 100% ;)
Have you guys tried since version 7.48? That's the version on Steam right now.
I was playing in public games yesterday and a bot joined.... So, of course, I expected to crash. I continued to play for 45 minutes while the bot player spammed out beams literally everywhere. Not a single crash.
I haven't tried to play the bot myself and I wouldn't assume the issue we were seeing was fixed just from the experience last night. That sort of aligns with my previous experience - I might crash in the first second of a proton beam being placed or run fine for an hour. What an annoying bug. :\
(In reply to comment #8)
> Have you guys tried since version 7.48? That's the version on Steam right
> now.
>
> I was playing in public games yesterday and a bot joined.... So, of course,
> I expected to crash. I continued to play for 45 minutes while the bot
> player spammed out beams literally everywhere. Not a single crash.
>
> I haven't tried to play the bot myself and I wouldn't assume the issue we
> were seeing was fixed just from the experience last night. That sort of
> aligns with my previous experience - I might crash in the first second of a
> proton beam being placed or run fine for an hour. What an annoying bug. :\
Reading this I got a bit hopeful that maybe something had been done to sort this issue out. So I jumped on my bot and summoned some beams into the tavern in local play. Less than five minutes later it crashed. So seems like it's not fixed yet.
Confirmed here too on Archlinux 64-bit, NVIDIA 313.30.
The segfault is indeed triggered by some beams, and not only EV ones. For instance the King of Genies boss uses lazer beams attacks that made me crash several times aswell.
It happens pretty randomly. Can crash immediately or after some minutes, but I noticed it is more likely to happen under heavy load.
Without EV/boss beams the game is stable and never crashes. All other classes' defenses/spells never cause issues either.
This is a pretty annoying issue, since the EV is quite useful if not mandatory for high level maps...
Alright, I'm mid/high-level (80) now and now this bug seriously annoys me.
The EV's Tower Buff Beam is so commonly used on Nightmare difficulty that it's impossible to progress any further in the game - because wherever you join, everyone on any mid-to-high-level maps uses EV's buff beams (for good reason), which cause the Linux version in combination with nvidia drivers to crash.
Sad to say, but in the current state this linux port is nothing more than a sneak peek to the game, because once you reach a certain level and want to progress further in the game - you just can't. Which takes the major part of the game - the end game - away from you.
It's sad that this bug has been open for almost half a year and no official seems to care about it.
(In reply to comment #12)
> It's sad that this bug has been open for almost half a year and no official
> seems to care about it.
In all fairness, there's only one official for all the linux port bugs (as far as I can tell anyways), and he's also the only person for the linux ports of numerous other games. So in that sense, he does a pretty good job.
However, this is not marked as a critical bug for no reason and it would be nice to know if this has even been looked into, if our idea of the beam code being the issue has been debunked (and we should keep testing), or if this has already been fixed and is due in the next update (I haven't given up hope of that suddenly happening yet).
Debian Wheezy amd64, using Nvidia 319.12 64 bit.
It appears I have the same issue.
I have experienced 1 crash with other classes than Series EV, but with Series EV I must have had 15 crashes and completing a level before a crash is pretty unlikely.
I tested using different lengths of proton beams, and it might be a bit less prone to crashing when using only 2 DU beams, but not sure if that's just random as I didn't test it for several hours (it still crashed, but I was online for more waves before doing so).
Started steam for the first time in a while and noticed it downloaded an update for Dungeon Defenders. Was a few hundred MB, can't remember exactly.
Immediately got that feeling you know... that it's been fixed...
Jumped on the Series EV, messed around in the tavern a bit in a local game putting up towers, jumping, shooting and it looked good...
For about two minutes. Then it crashed again with segmentation fault.
I don't even feel like playing it at the moment since it can crash at any time and ruin multiple hours of effort.
Anyone else try it lately?
This is REALLY ANNOYING bug!!!
All lowers levels were fine but now that my char is lvl80 I cannot play this game anymore. Only way to progress futher is nightmare and there is always some series ev or other that causes the game to crash. I had no problem with lower difficulties.
I've disabled steam overlay.. no effect.
I think probability of crashing is higher if game contains both: a lot of monk auras and series ev defenses.
Personally I gave up and I'm just playing it on Windows.
It's really sad because this is such a great game for Linux but its middle-end game is totally unplayable because of this. How would game editors ever take the Linux market seriously if we are unable to play their games correctly ?
Also no news from the maintainer(s) since months so I'm not really confident about the future. The godly-annoying non-magnet mana bug still has to be fixed aswell.
Hint: It works really flawlessly with wine - also the mana magneting.
Unfortunately, to say.
I switched to it, cause they don't give a damn about us.
And yes @Erich, what they do here _is_ sad. This is not a spare-time project done by 1 guy where it's totally reasonable if something takes longer.
No, Trendy makes money with it. We paid for it. Icculus gets paid.
It's understandable that many devs may not have much experience with this "new" platform. But anyway - this is business. If Ryan doesn't have the knowledge or can't handle it all by himself, someone else has to be hired to support him. Period.
(In reply to comment #19)
noother, I understand how you feel and you make some valid points. But this is a one person team and without him, I highly doubt we would have seen a port of this game. I also don't think devs will be very ambitious to port there game over to linux with complaints like this. Personally, if Ryan and myself ever cross paths. I'd like to shake his hand and thank him for his work because without it... instead of complaining about certain bugs we would be complaining about not having games to play, again.
This bug is still open because it's still on the TODO list, as are hundreds of bugs across dozens of other games. There are only so many hours in the day. Your patience is appreciated as we try to get through all the issues.
Thanks,
--ryan.
Is there any update on this issue? Like any beta build somebody could try out or any information about the crash or any help? I started to play this game again with some friends and really want to use the EV, but the game crashes too often. Wouldn't be a problem if it wouldn't be that bad if the crashes were less frequent like every fifth game or whatever.
I experience this problem as well, Series EV is very strong and when playing with my friends, it ruins our evening ;o(
playing on linux (current manjaro / arch) x86_64, nvidia 349.16
willing to help on the bug hunt.
maybe this backtrace helps: #0 __memcpy_ssse3_rep () at ../sysdeps/i386/i686/multiarch/memcpy-ssse3-rep.S:302 #1 0xf763d4ee in memcpy (__len=648, __src=0xabffad90, __dest=0xbfc2cdb0) at /usr/include/bits/string3.h:51 #2 copy_array_to_vbo_array (brw=brw@entry=0xa4bd12c, element=element@entry=0xa4dcf24, min=0, max=8, buffer=0xa4dcfe4, dst_stride=72) at brw_draw_upload.c:377 #3 0xf763e19a in brw_prepare_vertices (brw=0xa4bd12c) at brw_draw_upload.c:553 #4 0xf763e33b in brw_emit_vertices (brw=0xa4bd12c) at brw_draw_upload.c:652 #5 0xf76aafd0 in brw_upload_state (brw=0xa4bd12c) at brw_state_upload.c:648 #6 0xf763cfe6 in brw_try_draw_prims (ctx=ctx@entry=0xa4bd12c, arrays=arrays@entry=0xa51704c, prims=0xf4bfe040, nr_prims=1, ib=0xf4bfe030, min_index=0, max_index=8, indirect=0x0) at brw_draw.c:514 #7 0xf763d343 in brw_draw_prims (ctx=0xa4bd12c, prims=0xf4bfe040, nr_prims=1, ib=0xf4bfe030, index_bounds_valid=1 '\001', min_index=0, max_index=8, unused_tfb_object=0x0, indirect=0x0) at brw_draw.c:607 #8 0xf74d680e in vbo_validated_drawrangeelements (ctx=ctx@entry=0xa4bd12c, mode=mode@entry=5, index_bounds_valid=1 '\001', start=0, end=8, count=10, type=5123, indices=0xe48122e0, basevertex=0, numInstances=1, baseInstance=0) at vbo/vbo_exec_array.c:992 #9 0xf74d6b1a in vbo_exec_DrawRangeElementsBaseVertex (mode=5, start=0, end=8, count=10, type=5123, indices=0xe48122e0, basevertex=0) at vbo/vbo_exec_array.c:1086 #10 0xf74d6b47 in vbo_exec_DrawRangeElements (mode=5, start=0, end=8, count=10, type=5123, indices=0xe48122e0) at vbo/vbo_exec_array.c:1106 ---Type <return> to continue, or q <return> to quit--- #11 0x08b72238 in FMeshDrawingPolicy::DrawMesh(FMeshElement const&) const () #12 0x08c9d932 in void FDrawTranslucentMeshAction::Process<FNoLightMapPolicy, FNoDensityPolicy>(FProcessBasePassMeshParameters const&, FNoLightMapPolicy const&, FNoLightMapPolicy::ElementDataType const&, FNoDensityPolicy::ElementDataType const&) const () #13 0x08c9da66 in void ProcessBasePassMesh_LightMapped<FDrawTranslucentMeshAction, FNoLightMapPolicy>(FProcessBasePassMeshParameters const&, FDrawTranslucentMeshAction const&, FNoLightMapPolicy const&, FNoLightMapPolicy::ElementDataType const&) () #14 0x08c6355e in void ProcessBasePassMesh<FDrawTranslucentMeshAction>(FProcessBasePassMeshParameters const&, FDrawTranslucentMeshAction const&) [clone .constprop.933] () #15 0x08c65bd0 in FTranslucencyDrawingPolicyFactory::DrawDynamicMesh(FViewInfo const&, FTranslucencyDrawingPolicyFactory::ContextType, FMeshElement const&, unsigned int, unsigned int, FPrimitiveSceneInfo const*, FHitProxyId) () #16 0x08b9ea28 in TDynamicPrimitiveDrawer<FTranslucencyDrawingPolicyFactory>::DrawMesh(FMeshElement const&) () #17 0x08d2cb0a in FDynamicBeam2EmitterData::Render(FParticleSystemSceneProxy*, FPrimitiveDrawInterface*, FSceneView const*, unsigned int) [clone .part.220] () #18 0x08cfa261 in FParticleSystemSceneProxy::DrawDynamicElements(FPrimitiveDrawInterface*, FSceneView const*, unsigned int, unsigned int) [clone .part.284] () #19 0x08c66deb in FTranslucentPrimSet::Draw(FViewInfo const&, unsigned int, unsigned int) const () #20 0x08c672f4 in FSceneRenderer::RenderTranslucency(unsigned int) () #21 0x08c0976b in FSceneRenderer::RenderDPGEnd(unsigned int, unsigned int, unsigned int&, unsigned int) () #22 0x08c1e858 in FSceneRenderer::Render() () #23 0x08c230c1 in RenderViewFamily_RenderThread(FSceneRenderer*) () #24 0x08c2319f in BeginRenderingViewFamily(FCanvas*, FSceneViewFamily const*)::FDrawSceneCommand::Execute() () #25 0x0839af6c in RenderingThreadMain() () #26 0x083bc188 in FRenderingThread::Run() () #27 0x08e4bbbb in FRunnableThreadMac::Run() () #28 0x08e4bbdf in FRunnableThreadMac::_ThreadProc(void*) () #29 0x49b4c11f in start_thread (arg=0xf4bffb40) at pthread_create.c:310 #30 0x49a5d74e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:122