Cool VL Viewer forum

Register • FAQ • Search • Login
View unanswered posts | View active topics It is currently 2025-08-26 14:24:49

Board index » Bug reports

All times are UTC




Reply to topic  Page 1 of 1
  [ 8 posts ] 
Print view Previous topic | Next topic 
Crashes immediately after TP 
Author Message
Amalia Illios

Joined: 2010-04-07 08:23:18
Posts: 215
Reply with quote
Post Crashes immediately after TP
Hi Henri,

I have observed this one several times now, with 1.26.5.4 and .3. It always happens immediately after teleporting, and after my AV is rendered at the destination (TP screen switched off). So far it has only plagued me with one specific outfit / look (fully non-mesh), but that might be unrelated. Cross-checking with 1.26.4.22, it never seems to happen. Maybe you can make something of it.

Love,
Lia


Attachments:
File comment: Debug information
201208191325.tar.bz2 [16.85 KiB]
Downloaded 178 times
2012-08-19 13:37:16
Profile
Henri Beauchamp

Joined: 2009-03-17 18:42:51
Posts: 6043
Reply with quote
Post Re: Crashes immediately after TP
That's an interesting bug... After some investigation, it seems due to a gcc optimization bug. gcc assumes that a memory location is always 16-bytes aligned and uses a SSE instruction that requires that alignment (instead of the slower but equivalent, non-aligned version) to load a SSE register. As a result, the program crashes whenever the memory location in question happens to be unaligned...

Here are the relevant lines in your stack trace:
Code:
5   unknown                            0xf7732410 [0xf7732410]
6   com.secondlife.indra.viewer        0x821dcea LLFace::getGeometryVolume(LLVolume const&, int const&, LLMatrix4 const&, LLMatrix3 const&, unsigned short const&, bool) + 4428

Which corresponds to the following source lines in llface.cpp (around line 1920):
Code:
   mVertexBuffer->getNormalStrider(norm, mGeomIndex, mGeomCount, map_range);
   F32* normals = (F32*)norm.get();

   for (S32 i = 0; i < num_vertices; ++i)
   {
      LLVector4a normal;
      mat_normal.rotate(vf.mNormals[i], normal);
      normal.normalize3fast();
      normal.store4a(normals);
      normals += 4;
   }


Which translates into the following disassembly:
Code:
   0x0821dc8b <+4333>:  movl   $0x0,0x10(%esp)
   0x0821dc93 <+4341>:  mov    0x350(%esp),%edx
   0x0821dc9a <+4348>:  movzwl 0x80(%edx),%edi
   0x0821dca1 <+4355>:  mov    %edi,0xc(%esp)
   0x0821dca5 <+4359>:  movzwl 0x82(%edx),%esi
   0x0821dcac <+4366>:  mov    %esi,0x8(%esp)
   0x0821dcb0 <+4370>:  lea    0x2e0(%esp),%ebx
   0x0821dcb7 <+4377>:  mov    %ebx,0x4(%esp)
   0x0821dcbb <+4381>:  mov    0x60(%edx),%ecx
   0x0821dcbe <+4384>:  mov    %ecx,(%esp)
   0x0821dcc1 <+4387>:  call   0x8db934a <LLVertexBuffer::getBinormalStrider(LLStrider<LLVector3>&, S32, S32, bool)>
   0x0821dcc6 <+4392>:  mov    0x2e0(%esp),%ebx
   0x0821dccd <+4399>:  mov    0xb8(%esp),%ebp
   0x0821dcd4 <+4406>:  test   %ebp,%ebp
   0x0821dcd6 <+4408>:  jle    0x821d7d2 <LLFace::getGeometryVolume(LLVolume const&, S32 const&, LLMatrix4 const&, LLMatrix3 const&, U16 const&, bool)+3124>
   0x0821dcdc <+4414>:  xor    %ecx,%ecx  <-- That should be "i"
   0x0821dcde <+4416>:  xor    %edx,%edx  <-- That's 16 * i to point on next 16 bytes element each time: see the increment at 0x0821dd48
   0x0821dce0 <+4418>:  mov    0xb4(%esp),%esi  <-- That should be vf
   0x0821dce7 <+4425>:  mov    0x40(%esi),%eax  <-- That should be mNormals
   0x0821dcea <+4428>:  movaps (%eax,%edx,1),%xmm1  <-- The crash happens here. gcc should have used movups instead since (%eax,%edx,1) could eventually not be 16-bytes aligned...
   0x0821dcee <+4432>:  movaps %xmm1,%xmm7
   0x0821dcf1 <+4435>:  shufps $0x0,%xmm1,%xmm7
   0x0821dcf5 <+4439>:  mulps  0x220(%esp),%xmm7
   0x0821dcfd <+4447>:  movaps %xmm1,%xmm0
   0x0821dd00 <+4450>:  shufps $0x55,%xmm1,%xmm0
   0x0821dd04 <+4454>:  mulps  0x230(%esp),%xmm0
   0x0821dd0c <+4462>:  shufps $0xaa,%xmm1,%xmm1
   0x0821dd10 <+4466>:  mulps  0x240(%esp),%xmm1
   0x0821dd18 <+4474>:  addps  %xmm0,%xmm7
   0x0821dd1b <+4477>:  addps  %xmm1,%xmm7
   0x0821dd1e <+4480>:  movaps %xmm7,%xmm5
   0x0821dd21 <+4483>:  mulps  %xmm7,%xmm5
   0x0821dd24 <+4486>:  movdqa %xmm5,%xmm6
   0x0821dd28 <+4490>:  pshufd $0xe1,%xmm5,%xmm4
   0x0821dd2d <+4495>:  addps  %xmm4,%xmm5
   0x0821dd30 <+4498>:  movlhps %xmm5,%xmm5
   0x0821dd33 <+4501>:  pshufd $0xaa,%xmm6,%xmm3
   0x0821dd38 <+4506>:  addps  %xmm3,%xmm5
   0x0821dd3b <+4509>:  rsqrtps %xmm5,%xmm2
   0x0821dd3e <+4512>:  mulps  %xmm2,%xmm7
   0x0821dd41 <+4515>:  movaps %xmm7,(%ebx,%edx,1)
   0x0821dd45 <+4519>:  add    $0x1,%ecx
   0x0821dd48 <+4522>:  add    $0x10,%edx
   0x0821dd4b <+4525>:  cmp    %ecx,0xb8(%esp)
   0x0821dd52 <+4532>:  jg     0x821dce0 <LLFace::getGeometryVolume(LLVolume const&, S32 const&, LLMatrix4 const&, LLMatrix3 const&, U16 const&, bool)+4418>


Thing is... mat_normal is aligned (it's a LLMatrix4a which is designed to be aligned and used with SSE2), mNormals is a pointer on an aligned array (an array of LLVector4a's), and normal is aligned... So gcc doesn't seem to make completely unreasonable assumptions.

It would be interesting if you could reproduce the bug while running the viewer under gdb, and post the registers dump together with the stack trace: this way, we could see what went wrong.
2012-08-19 17:47:39
Profile WWW
Henri Beauchamp

Joined: 2009-03-17 18:42:51
Posts: 6043
Reply with quote
Post Re: Crashes immediately after TP
Yep, it seems to be a gcc issue... Here is the disassembly I get with a newer gcc (v4.4.3):

Quote:
0x08221df2 <+4312>: movl $0x0,0x10(%esp)
0x08221dfa <+4320>: movzwl 0x80(%ebp),%edx
0x08221e01 <+4327>: mov %edx,0xc(%esp)
0x08221e05 <+4331>: movzwl 0x82(%ebp),%esi
0x08221e0c <+4338>: mov %esi,0x8(%esp)
0x08221e10 <+4342>: lea 0x294(%esp),%edi
0x08221e17 <+4349>: mov %edi,0x4(%esp)
0x08221e1b <+4353>: mov 0x60(%ebp),%ebx
0x08221e1e <+4356>: mov %ebx,(%esp)
0x08221e21 <+4359>: call 0x8e52b82 <LLVertexBuffer::getBinormalStrider(LLStrider<LLVector3>&, S32, S32, bool)>
0x08221e26 <+4364>: mov 0x294(%esp),%eax
0x08221e2d <+4371>: cmpl $0x0,0x88(%esp)
0x08221e35 <+4379>: jle 0x82219e6 <LLFace::getGeometryVolume(LLVolume const&, S32 const&, LLMatrix4 const&, LLMatrix3 const&, U16 const&, bool)+3276>
0x08221e3b <+4385>: xor %ebx,%ebx
0x08221e3d <+4387>: xor %esi,%esi
0x08221e3f <+4389>: lea 0x1f0(%esp),%edi <-- mat_normal.rotate(vf.mNormals[i], normal); starts here....
0x08221e46 <+4396>: mov %ebp,0x70(%esp)
0x08221e4a <+4400>: mov %eax,%ebp
0x08221e4c <+4402>: mov %edi,0x8(%esp)
0x08221e50 <+4406>: mov %ebx,%eax
0x08221e52 <+4408>: mov 0x68(%esp),%edx
0x08221e56 <+4412>: add 0x40(%edx),%eax
0x08221e59 <+4415>: mov %eax,0x4(%esp)
0x08221e5d <+4419>: lea 0x170(%esp),%ecx
0x08221e64 <+4426>: mov %ecx,(%esp)
0x08221e67 <+4429>: call 0x8224e8e <LLMatrix4a::rotate(LLVector4a const&, LLVector4a&)> <-- and ends here: no movaps used to load a SSE register from memory !
0x08221e6c <+4434>: xorps %xmm7,%xmm7
0x08221e6f <+4437>: movlps 0x1f0(%esp),%xmm7
0x08221e77 <+4445>: movhps 0x1f8(%esp),%xmm7
0x08221e7f <+4453>: movaps %xmm7,%xmm6
0x08221e82 <+4456>: mulps %xmm7,%xmm6
0x08221e85 <+4459>: movdqa %xmm6,%xmm2
0x08221e89 <+4463>: pshufd $0xe1,%xmm6,%xmm0
0x08221e8e <+4468>: addps %xmm0,%xmm6
0x08221e91 <+4471>: movlhps %xmm6,%xmm6
0x08221e94 <+4474>: pshufd $0xaa,%xmm2,%xmm3
0x08221e99 <+4479>: addps %xmm3,%xmm6
0x08221e9c <+4482>: rsqrtps %xmm6,%xmm1
0x08221e9f <+4485>: mulps %xmm7,%xmm1
0x08221ea2 <+4488>: movlps %xmm1,0x1f0(%esp)
0x08221eaa <+4496>: movhps %xmm1,0x1f8(%esp)
0x08221eb2 <+4504>: movaps %xmm1,0x0(%ebp,%ebx,1)
0x08221eb7 <+4509>: add $0x1,%esi
0x08221eba <+4512>: add $0x10,%ebx
0x08221ebd <+4515>: cmp %esi,0x88(%esp)
0x08221ec4 <+4522>: jg 0x8221e4c <LLFace::getGeometryVolume(LLVolume const&, S32 const&, LLMatrix4 const&, LLMatrix3 const&, U16 const&, bool)+4402>


I will see if I can downgrade gcc to v4.1 (v1.26.4.22 and older releases were built with v4.1) or 4.2 on my build system (currently using 4.3.2), and see if it solves this issue.
2012-08-19 18:04:12
Profile WWW
Amalia Illios

Joined: 2010-04-07 08:23:18
Posts: 215
Reply with quote
Post Re: Crashes immediately after TP
Hi again Henri,

uhm ... :shock:

Ok, I'll take your word for it. Thank you so much for the time and energy you spend on all these crazy things!

Love,
Lia
2012-08-19 18:23:06
Profile
Henri Beauchamp

Joined: 2009-03-17 18:42:51
Posts: 6043
Reply with quote
Post Re: Crashes immediately after TP
I recompiled v1.26.4.25 and v1.26.5.4 with gcc v4.2.3. Not sure it will be much better than with v4.3.2 (the generated code is yet again different), but it's worth a try. Get them (v1.26.4.25b and v1.26.5.4b and let me know if it cures that crash for you.
2012-08-19 19:40:15
Profile WWW
Amalia Illios

Joined: 2010-04-07 08:23:18
Posts: 215
Reply with quote
Post Re: Crashes immediately after TP
Hi again Henri,

finally got around to trying 1.26.5.4b just now ... and no, it doesn't solve the issue, it seems. Here's what gdb tells me (added the end of log output as well, just in case):

Code:
2012-08-21T14:00:44Z INFO: process_agent_movement_complete: Changing home region to 463360:303360
2012-08-21T14:00:44Z INFO: LLAgent::setRegion: Moving agent into region: Crossbrook located at 216.82.48.187:13015
2012-08-21T14:00:44Z INFO: sendToSim: Sending throttle settings, total BW 9000
2012-08-21T14:00:44Z INFO: process_agent_movement_complete:  is_teleport =1
2012-08-21T14:00:44Z INFO: LLAgent::sendAgentSetAppearance: TAT: Sent AgentSetAppearance: head-baked_baked upper-baked_baked lower-baked_baked eyes-baked_baked skirt-baked hair-baked_baked
2012-08-21T14:00:45Z INFO: updateGeometry: WL Skydome strips in 2 batches.
2012-08-21T14:00:45Z INFO: updateGeometry: completed in 0.01 seconds
2012-08-21T14:00:45Z WARNING: callbackHttpGet: callbackHttpGet for unrequested fetch worker: ef7a0854-b1ca-1468-6d49-344aeb775cf6 req=1 state= 4
2012-08-21T14:00:45Z WARNING: callbackHttpGet: callbackHttpGet for unrequested fetch worker: f2a86622-684e-7b55-ba3c-15727c9bfed3 req=1 state= 4
2012-08-21T14:00:45Z WARNING: callbackHttpGet: callbackHttpGet for unrequested fetch worker: 20dc2922-9e89-9d4d-d90a-1180fb8b7e87 req=1 state= 4
2012-08-21T14:00:45Z WARNING: callbackHttpGet: callbackHttpGet for unrequested fetch worker: 2b081f46-7943-aef9-0a34-8fe6fb991fae req=1 state= 4

Program received signal SIGSEGV, Segmentation fault.
0x08288524 in LLFace::getGeometryVolume(LLVolume const&, int const&, LLMatrix4 const&, LLMatrix3 const&, unsigned short const&, bool) ()
(gdb) bt                             
#0  0x08288524 in LLFace::getGeometryVolume(LLVolume const&, int const&, LLMatrix4 const&, LLMatrix3 const&, unsigned short const&, bool) ()
#1  0x08ea9fd7 in LLVolumeGeometryManager::rebuildMesh(LLSpatialGroup*) ()
#2  0x08a6e9a0 in LLSpatialGroup::rebuildMesh() ()
#3  0x08f537c7 in LLPipeline::stateSort(LLCamera&, LLCullResult&) ()
#4  0x08f553ac in LLPipeline::renderShadow(glh::ns_float::matrix4&, glh::ns_float::matrix4&, LLCamera&, LLCullResult&, int, int, unsigned int) ()
#5  0x08f5979b in LLPipeline::generateSunShadow(LLCamera&) ()
#6  0x08bcc587 in display(int, float, int, int) ()
#7  0x081cc1cc in LLAppViewer::mainLoop() ()
#8  0x08fbccca in main ()
(gdb) info all-registers
eax            0xa      10
ecx            0x0      0
edx            0x5cbe8550       1555989840
ebx            0x5cbe8550       1555989840
esp            0xffffb8a0       0xffffb8a0
ebp            0x0      0x0
esi            0x4e7096e4       1316001508
edi            0x263e1380       641602432
eip            0x8288524        0x8288524 <LLFace::getGeometryVolume(LLVolume const&, int const&, LLMatrix4 const&, LLMatrix3 const&, unsigned short const&, bool)+6538>
eflags         0x10246  [ PF ZF IF RF ]
cs             0x23     35
ss             0x2b     43
ds             0x2b     43
es             0x2b     43
fs             0x0      0
gs             0x63     99
st0            -0.029317386656072481583497650256542322  (raw 0xbff9f02b041c8b698f46)
st1            -0       (raw 0x80000000000000000000)
st2            0        (raw 0x00000000000000000000)
st3            1024     (raw 0x40098000000000000000)
st4            7168     (raw 0x400be000000000000000)
st5            1        (raw 0x3fff8000000000000000)
st6            -1       (raw 0xbfff8000000000000000)
st7            128      (raw 0x40068000000000000000)
fctrl          0x37f    895
fstat          0x23     35
ftag           0xffff   65535
fiseg          0x0      0
fioff          0x0      0
foseg          0x0      0
fooff          0x0      0
fop            0x0      0
xmm0           {v4_float = {0xe50, 0xe50, 0xe50, 0xe50}, v2_double = {0x8000000000000000, 0x8000000000000000}, v16_int8 = {0x0, 0x8, 0x65, 0x45, 0x0,
    0x8, 0x65, 0x45, 0x0, 0x8, 0x65, 0x45, 0x0, 0x8, 0x65, 0x45}, v8_int16 = {0x800, 0x4565, 0x800, 0x4565, 0x800, 0x4565, 0x800, 0x4565}, v4_int32 = {
    0x45650800, 0x45650800, 0x45650800, 0x45650800}, v2_int64 = {0x4565080045650800, 0x4565080045650800}, uint128 = 0x45650800456508004565080045650800}
xmm1           {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x1d, 0x54, 0xb2, 0x3d, 0xd9, 0x99, 0x70, 0xbf, 0xf8, 0x2f, 0xa9,
    0x3e, 0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x541d, 0x3db2, 0x99d9, 0xbf70, 0x2ff8, 0x3ea9, 0x0, 0x0}, v4_int32 = {0x3db2541d, 0xbf7099d9, 0x3ea92ff8,
    0x0}, v2_int64 = {0xbf7099d93db2541d, 0x3ea92ff8}, uint128 = 0x000000003ea92ff8bf7099d93db2541d}
xmm2           {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x61, 0xb2, 0xb, 0x32, 0x61, 0xb2, 0xb, 0x32, 0x61, 0xb2, 0xb,
    0x32, 0x61, 0xb2, 0xb, 0x32}, v8_int16 = {0xb261, 0x320b, 0xb261, 0x320b, 0xb261, 0x320b, 0xb261, 0x320b}, v4_int32 = {0x320bb261, 0x320bb261,
    0x320bb261, 0x320bb261}, v2_int64 = {0x320bb261320bb261, 0x320bb261320bb261}, uint128 = 0x320bb261320bb261320bb261320bb261}
xmm3           {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x22, 0x6d, 0x4b, 0xb7, 0xd2, 0x4f, 0x85, 0xb9, 0x23, 0xf7, 0xbf,
    0x38, 0x0, 0x0, 0x0, 0x80}, v8_int16 = {0x6d22, 0xb74b, 0x4fd2, 0xb985, 0xf723, 0x38bf, 0x0, 0x8000}, v4_int32 = {0xb74b6d22, 0xb9854fd2,
    0x38bff723, 0x80000000}, v2_int64 = {0xb9854fd2b74b6d22, 0x8000000038bff723}, uint128 = 0x8000000038bff723b9854fd2b74b6d22}
xmm4           {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x3b, 0x42, 0x8d, 0x33, 0x42, 0x33, 0x1b, 0x30, 0x61, 0xb2, 0xb,
    0x32, 0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x423b, 0x338d, 0x3342, 0x301b, 0xb261, 0x320b, 0x0, 0x0}, v4_int32 = {0x338d423b, 0x301b3342, 0x320bb261,
    0x0}, v2_int64 = {0x301b3342338d423b, 0x320bb261}, uint128 = 0x00000000320bb261301b3342338d423b}
xmm5           {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0xa6, 0x2a, 0xb5, 0x35, 0x6a, 0xea, 0x37, 0xb6, 0x9d, 0x71, 0xf9,
    0xb6, 0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x2aa6, 0x35b5, 0xea6a, 0xb637, 0x719d, 0xb6f9, 0x0, 0x0}, v4_int32 = {0x35b52aa6, 0xb637ea6a, 0xb6f9719d,
    0x0}, v2_int64 = {0xb637ea6a35b52aa6, 0xb6f9719d}, uint128 = 0x00000000b6f9719db637ea6a35b52aa6}
xmm6           {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x42, 0x33, 0x1b, 0x30, 0x3b, 0x42, 0x8d, 0x33, 0x61, 0xb2, 0xb,
    0x32, 0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x3342, 0x301b, 0x423b, 0x338d, 0xb261, 0x320b, 0x0, 0x0}, v4_int32 = {0x301b3342, 0x338d423b, 0x320bb261,
    0x0}, v2_int64 = {0x338d423b301b3342, 0x320bb261}, uint128 = 0x00000000320bb261338d423b301b3342}
xmm7           {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0xee, 0xee, 0x9f, 0x33, 0xee, 0xee, 0x9f, 0x33, 0xee, 0xee, 0x9f,
    0x33, 0xee, 0xee, 0x9f, 0x33}, v8_int16 = {0xeeee, 0x339f, 0xeeee, 0x339f, 0xeeee, 0x339f, 0xeeee, 0x339f}, v4_int32 = {0x339feeee, 0x339feeee,
    0x339feeee, 0x339feeee}, v2_int64 = {0x339feeee339feeee, 0x339feeee339feeee}, uint128 = 0x339feeee339feeee339feeee339feeee}
mxcsr          0x9fbf   [ IE DE ZE OE UE PE IM DM ZM OM UM PM FZ ]
mm0            {uint64 = 0xf02b041c8b698f46, v2_int32 = {0x8b698f46, 0xf02b041c}, v4_int16 = {0x8f46, 0x8b69, 0x41c, 0xf02b}, v8_int8 = {0x46, 0x8f,
    0x69, 0x8b, 0x1c, 0x4, 0x2b, 0xf0}}
mm1            {uint64 = 0x0, v2_int32 = {0x0, 0x0}, v4_int16 = {0x0, 0x0, 0x0, 0x0}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}}
mm2            {uint64 = 0x0, v2_int32 = {0x0, 0x0}, v4_int16 = {0x0, 0x0, 0x0, 0x0}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}}
mm3            {uint64 = 0x8000000000000000, v2_int32 = {0x0, 0x80000000}, v4_int16 = {0x0, 0x0, 0x0, 0x8000}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0,
    0x0, 0x0, 0x80}}
mm4            {uint64 = 0xe000000000000000, v2_int32 = {0x0, 0xe0000000}, v4_int16 = {0x0, 0x0, 0x0, 0xe000}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0,
    0x0, 0x0, 0xe0}}
mm5            {uint64 = 0x8000000000000000, v2_int32 = {0x0, 0x80000000}, v4_int16 = {0x0, 0x0, 0x0, 0x8000}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0,
    0x0, 0x0, 0x80}}
mm6            {uint64 = 0x8000000000000000, v2_int32 = {0x0, 0x80000000}, v4_int16 = {0x0, 0x0, 0x0, 0x8000}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0,
    0x0, 0x0, 0x80}}
mm7            {uint64 = 0x8000000000000000, v2_int32 = {0x0, 0x80000000}, v4_int16 = {0x0, 0x0, 0x0, 0x8000}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0,
    0x0, 0x0, 0x80}}
(gdb)


I hope this helps shed some light on it.

Love,
Lia
2012-08-21 14:17:01
Profile
Henri Beauchamp

Joined: 2009-03-17 18:42:51
Posts: 6043
Reply with quote
Post Re: Crashes immediately after TP
Yes, it does shed some light... The disassembly for the crash point is:
Code:
0x08288524 <+6538>:  movaps 0x0(%ebp),%xmm5
and the register dump shows that at this point, %ebp contains 0, meaning we are trying to load the data contained at address 0 into %xmm5, which of course causes a segmentation fault...

The corresponding C++ code is:
Code:
mat_normal.rotate(vf.mBinormals[i], binormal)
and, apparently, vf.mBinormals[i] is pointing to address 0, which is no good ! Now the question is why...

Looking at the code again, and again, I can't find a valid reason. mVertexBuffer->getBinormalStrider() could eventually fail (and since the code doesn't test for its return boolean, it would try and use wrong buffer pointers), but then there should be the corresponding "mapVertexBuffer failed!" message in the log (from indra/llrender/llvertexbuffer.cpp, around line 2000), which is not the case.

I'm clueless (and so far couldn't reproduce this bug here). Could you try and disable the VBOs in the Graphics Hardware settings and see if it still happens for you ?

Also, it would be interesting to try and reproduce that bug with LL's official viewer (3.3.4 or 3.4)... If it also happens with it then, by all means, file a JIRA for it !

Finally, for other readers: is anyone else encountering the same crash bug ?
2012-08-21 19:35:01
Profile WWW
Amalia Illios

Joined: 2010-04-07 08:23:18
Posts: 215
Reply with quote
Post Re: Crashes immediately after TP
Henri Beauchamp wrote:
I'm clueless (and so far couldn't reproduce this bug here). Could you try and disable the VBOs in the Graphics Hardware settings and see if it still happens for you ?
I can certainly give that a try. :D
Henri Beauchamp wrote:
Also, it would be interesting to try and reproduce that bug with LL's official viewer (3.3.4 or 3.4)...
I suppose I could do that as well. :)
Henri Beauchamp wrote:
If it also happens with it then, by all means, file a JIRA for it !
Uhm, ok. :shock:
Henri Beauchamp wrote:
Finally, for other readers: is anyone else encountering the same crash bug ?
That would indeed be interesting to know. It seems to require some very specific circumstances, though. My initial theory about my wearing a specific outfit for it to happen hasn't been disproven yet. Plus it also might have to do with the destination, but that one's still vague.

Come to think of it, I also might run a test in which I turn the TP-screen back on. Maybe it's some form of it trying to render something which isn't 'there' yet?

Love,
Lia
2012-08-22 06:16:59
Profile
Display posts from previous:  Sort by  
Reply to topic   Page 1 of 1
  [ 8 posts ] 

Board index » Bug reports

All times are UTC


Who is online

Users browsing this forum: No registered users and 149 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.