Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#4130 closed bug (fixed)

[Tracker] crash in Model::StatChanged ()

Reported by: diver Owned by: aldeck
Priority: normal Milestone: R1
Component: Applications/Tracker Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking: #4271, #4610, #4831, #4845
Has a Patch: no Platform: All

Description

I tried to zip Desktop folder using:

zip -yr Desktop.zip Desktop/

I have an opened query window for "zip"
As soon as i executed this command tracker crashed.
See screenshot
hrev31814 in virtualbox

Attachments (1)

tracker_crash.png (133.0 KB) - added by diver 10 years ago.

Download all attachments as: .zip

Change History (10)

Changed 10 years ago by diver

Attachment: tracker_crash.png added

comment:1 Changed 10 years ago by bonefish

Also encountered in hrev32727 alpha 1 branch.

00114b90 <BPrivate::Model::StatChanged(void)>:
  114b90:       55                      push   %ebp
  114b91:       89 e5                   mov    %esp,%ebp
  114b93:       83 ec 0c                sub    $0xc,%esp
  114b96:       57                      push   %edi
  114b97:       56                      push   %esi
  114b98:       53                      push   %ebx
  114b99:       e8 00 00 00 00          call   114b9e <BPrivate::Model::StatChanged(void)+0xe>
  114b9e:       5b                      pop    %ebx
  114b9f:       81 c3 a6 c4 0c 00       add    $0xcc4a6,%ebx
  114ba5:       8b 7d 08                mov    0x8(%ebp),%edi
  114ba8:       8b 77 1c                mov    0x1c(%edi),%esi
  114bab:       83 c4 f8                add    $0xfffffff8,%esp
  114bae:       8b 57 74                mov    0x74(%edi),%edx
  114bb1:       8b 4a 10                mov    0x10(%edx),%ecx

The last instruction is the point of crash; %edx is NULL. %edi should be the object pointer and 0x74(%edi) the fNode member. So apparently the Model's fNode member is NULL.

I've already seen the bug several times. It usually happens with a tracker window for a directory in which a lot of file adding/removing is happing. Easy to reproduce with:

mkdir /tmp/tt; cd /tmp/tt; open .; while true; do touch $(seq 100); rm $(seq 100); done

comment:2 Changed 10 years ago by aldeck

Owner: changed from axeld to aldeck
Status: newassigned

Thanks for the test case. Very well reproducible indeed. On it

comment:3 Changed 10 years ago by aldeck

Resolution: fixed
Status: assignedclosed

Fixed in hrev33744

comment:4 Changed 10 years ago by aldeck

Blocking: 4831 added

(In #4831) Duplicate of #4130, fixed by hrev33744.

for reference, the last bug i wanted to refer to in the previous comment was #4271.

comment:5 Changed 10 years ago by aldeck

Blocking: 4271 added

(In #4271) Most certainly a duplicate of #4130, fixed in hrev33744. Please test

comment:6 Changed 10 years ago by aldeck

Blocking: 4610 added

(In #4610) Most probably a duplicate of #4130, fixed by hrev33744. Please test

comment:7 Changed 10 years ago by aldeck

The fix in hrev33744 wasn't correct as it would stop to manage moved/renamed files. More correct fix in hrev33768

comment:8 Changed 10 years ago by aldeck

sorry, previous comment should have said hrev33769

comment:9 Changed 10 years ago by aldeck

Blocking: 4845 added

(In #4845) Ok, then chances are very high that this is a duplicate of #4130. Just reopen if you see it again on revisions > hrev33769. Thanks for testing. Btw i'm curious what is that scripting tool you are using?

Note: See TracTickets for help on using tickets.