This issue is related to the problem with Forticlient+pipelining filed at BUG-8631 but symptoms are different in that there is no obvious visible corruption of mesh & textures and the crash takes longer to reproduce unless you are in a busy area, so I thought it was worth a seperate issue.

Steps To Reproduce

• Install Norman AV Security Suite - the trial version is fine to reproduce the problem: http://www.norman.com/en/home_and_small_office/trials_downloads/free_trial_for_norman_security_suite_pro

• Update to the latest virus definitions and reboot the computer.

• You do not need to change any settings in Norman AV Security Suite after installation - out of the box settings will reproduce the problem.

• Clean viewer cache and make sure that HttpPipelining is enabled and login.

• If you get a BSOD as soon as the world starts to render (see "Observed behaviour") reboot and login again.

• Pay close attention to your surroundings to see if you see any corrupted textures or mesh.

• If you have not crashed already, teleport to a busy area, for example http://maps.secondlife.com/secondlife/Fawlty%20Towers/45/58/901

• Cam about and observe surroundings.

• Once crash has been reproduced, clear viewer cache and disable HttpPipelining and repeat the above steps.

• Compare viewer logs from a clean cache session with HttpPipelining enabled and a clean cache session with HttpPipelining disabled.

  Observed Behaviour

  HttpPipelining Enabled

• Sometimes the system will BSOD just after login a few seconds after you see the world start to render.
  See comments section.

• When you login to a quiet region, everything appears visibly normal - look hard enough and you will see the odd corrupted texture (rainbow coloured) or a mesh that is not loading correctly (stuck as triangles) but the visible corruption is nowhere near as bad as that seen when using Forticlient with Pipelining enabled (BUG-8631).

• If you stay on a quiet region, the viewer will take a fairly long time to crash - at least half an hour.

• After teleporting into a busy region, there are still no obvious signs of mesh or texture corruption.

• Even though everything appears fine visibly, logs tell a different story.
  The same warnings are seen in logs as when using Forticlient with pipelining enabled.

  Lots of these:

  2015-03-07T23:11:22Z WARNING: LLMeshHandlerBase::onCompleted: Mesh response (bytes [1024..3829]) didn't overlap with request's origin (bytes [885..3765]).
  2015-03-07T23:11:22Z WARNING: LLMeshLODHandler::processFailure: Error during mesh LOD handling.  ID:  f592bd1c-efe6-3df8-69d8-c8ac0f705386, Reason:  Invalid Content-Range header encountered (Core_4).  Not retrying.
  2015-03-07T23:11:22Z WARNING: LLMeshLODHandler::processData: Error during mesh LOD processing.  ID:  9821dce4-c490-db72-05f6-4a7d9e29b2b5, Unknown reason.  Not retrying.

  The logs are also always full of KDU blowups

  2015-03-07T23:10:39Z INFO: LLKDUMessageError::put_text: KDU Error: Kakadu Core Error:
  
  2015-03-07T23:10:39Z INFO: LLKDUMessageError::put_text: KDU Error: Illegal inclusion tag tree encountered while decoding a packet header.  This problem can arise if empty packets are used (i.e., packets whose first header bit is 0) and the value coded by the inclusion tag tree in a subsequent packet is not exactly equal to the index of the quality layer in which each code-block makes its first contribution.  Such an error may arise from a mis-interpretation of the standard.  The problem may also occur as a result of a corrupted code-stream.  Try re-opening the image with the resilient mode enabled.

• The viewer will usually crash within minutes of entering a busy region
  Like the BUG-8631 crash, there is often not a dmp generated when the viewer crashes, you just get a windows dialog saying "Second Life has stopped working..."

  When the viewer does produce a dmp file, the callstack appears to be the same crash as when using Forticlient:

  >	ntdll.dll!_RtlReportCriticalFailure@8()  + 0x57 bytes	
   	ntdll.dll!_RtlpReportHeapFailure@4()  + 0x21 bytes	
   	ntdll.dll!_RtlpLogHeapFailure@24()  + 0xa1 bytes	
   	ntdll.dll!_RtlFreeHeap@12()  + 0x500a0 bytes	
   	kernel32.dll!_HeapFree@12()  + 0x14 bytes	
   	msvcr100.dll!_free()  + 0x1c bytes	
   	msvcr100.dll!__aligned_free()  + 0x17 bytes	

• See Whirly_HttpPipelining_enabled logs attached for a session ending in a crash (no dmp unfortunately).

  HttpPipelining Disabled

• No texture or mesh corruption at all.

• None of the above warnings or KDU blowups in the session logs.
  Note that if you had a cache fetched with pipelining enabled, you will still see the KDU blowups in the logs when Pipelining is disabled if you did not clear cache.

• Viewer does not crash.

• No system BSODs

• See Whirly_HttpPipelining_disabled logs attached for a session visiting the same regions with Pipelining disabled.

  Expected Behaviour

  Not to crash frequently when HttpPipelining is enabled when using Norman Antivirus Security Suite

  Other Information.

• This problem with Norman Antivirus Security Suite causing Pipelining enabled viewers to crash was initially reported by one of the Firestorm beta testers - see http://jira.phoenixviewer.com/browse/FIRE-15677
  Disabling HttpPipelining also fixed the crashes for this user.

• I dont think this crash is network related, since I do not crash when using AVG antivirus with Pipelining enabled viewers, but here is my network info just incase:

Network Information

• Router make: TP-Link

• Router Model: TD-W8961ND

• Software version: Firmware Version: 3.0.0 Build 120808 Rel.28888, ADSL Firmware Version: FwVer:3.20.17.0_TC3087 HwVer:T14.F7_11.2

• IP Address: 88.104.228.205 (not static)

• ISP: TalkTalk

• Hardwired to router, standard broadband.

  C:\Users\Whirly>tracert login.agni.lindenlab.com
  
  Tracing route to login.agni.lindenlab.com [216.82.54.28]
  over a maximum of 30 hops:
  
    1    <1 ms    <1 ms    <1 ms  192.168.1.1
    2    19 ms    19 ms    22 ms  88-104-224-1.dynamic.dsl.as9105.com [88.104.224.1]
    3    25 ms    24 ms    24 ms  85-210-252-0.dynamic.dsl.as9105.com [85.210.252.0]
    4    24 ms    25 ms    26 ms  85-210-252-184.dynamic.dsl.as9105.com [85.210.252.184]
    5    30 ms    31 ms    30 ms  host-78-144-9-5.as13285.net [78.144.9.5]
    6    30 ms    30 ms    31 ms  host-78-144-13-34.as13285.net [78.144.13.34]
    7    32 ms    32 ms    32 ms  unknown.Level3.net [212.187.192.113]
    8   164 ms   156 ms   156 ms  ae-1-8.bar1.Phoenix1.Level3.net [4.69.133.29]
    9     *      156 ms     *     ae-1-8.bar1.Phoenix1.Level3.net [4.69.133.29]
   10     *        *      187 ms  LINDEN-RESE.bar1.Phoenix1.Level3.net [4.53.104.14]
   11     *        *        *     Request timed out.
   12     *        *        *     Request timed out.
   13   184 ms   183 ms   158 ms  login-phx3.agni.lindenlab.com [216.82.54.28]
  
  Trace complete.

Attachments

• Whirly_HttpPipelining_disabled.zip 2015-03-07 19:18:08
• Whirly_HttpPipelining_enabled.zip 2015-03-07 18:25:02

Links

Related

• [BUG-8631] Complete texture corruption followed by viewer crash, only when HttpPipelining is enabled #16223

{
  'Business Unit': ['Platform'],
  'Severity': 'Unset',
  'System': 'SL Viewer',
  'Target Viewer Version': 'viewer-development',
  'What just happened?': '.',
  'What were you doing when it happened?': 'Filling in...',
  'What were you expecting to happen instead?': '.',
}