crash upon hitting <ctrl>+<home>

[grunt]

hi guys.

latest build has segfaulted on me about half a dozen times when i hit <htrl>+<home> combo in 3-way merge. it doesn't happen every time i hit this key combo, just occasionally, and so far i haven't been able to pinpoint the exact combination of factors that triggers this one. no dialog boxes displayed, no nothing - just a regular tiny segfault blurb.

git-mergetool acts rather dumb if the 3-way merge tool drops dead from under its feet like this forcing me to re-merge all anew, so i'd really-really like to see this resolved. :) is there any way i can help you here without disclosing any proprietary information (paths/files/hosts/etc.)? debug builds? cores? anything?

[Jacques]

I guess I'm not sure what you are trying to do. By default <Ctrl+Home> jumps to the top of the text file. Did you map <Ctrl+Home> to a custom command? Thanks.

[grunt]

I guess I'm not sure what you are trying to do. By default <Ctrl+Home> jumps to the top of the text file.
and that's exactly what I'm trying to do.

Did you map <Ctrl+Home> to a custom command?not that i'm aware of.

[Jacques]

OK, unfortunately I wasn't able to reproduce this. Have you noticed this in other session types? Are you using a build prior to 453? Which distribution are you using?

Perhaps a core dump could prove useful. Could you send one to mailto:support@scootersoftware.com, hopefully it won't bounce.

[Michael Bulgrien]

I, too, tried to reproduce this issue without success (except that I was not launching the merge session from source control, which may be why I could not reproduce it.) Just curious, what OS are you using, grunt?

[grunt]

as an aside, does that look right? at the moment i'm running AT MOST one instance (can't say for sure if even that - i'm away from the box, looking in through ssh).

1 S username 9875 9584 0 75 0 - 9076 - Apr14 ? 00:01:05 kdeinit: konsole
0 S username 16063 9875 0 75 0 - 1404 wait Apr24 pts/6 00:00:03 bash
0 S username 21972 16063 0 76 0 - 25768 - Apr24 pts/6 00:03:07 /usr/bin/bcompare
1 S username 21997 21972 0 76 0 - 25768 - Apr24 pts/6 00:00:00 /usr/bin/bcompare
1 S username 21998 21997 0 76 0 - 25768 rt_sig Apr24 pts/6 00:00:00 /usr/bin/bcompare
1 S username 21999 21997 0 75 0 - 25768 rt_sig Apr24 pts/6 00:00:02 /usr/bin/bcompare
1 S username 22089 21997 0 77 0 - 25768 rt_sig Apr24 pts/6 00:00:00 /usr/bin/bcompare
1 S username 22563 21997 0 76 0 - 25768 rt_sig Apr24 pts/6 00:00:00 /usr/bin/bcompare
1 S username 22629 21997 0 76 0 - 25768 rt_sig Apr24 pts/6 00:00:00 /usr/bin/bcompare
1 S username 23278 21997 0 77 0 - 25768 rt_sig Apr24 pts/6 00:00:00 /usr/bin/bcompare
1 S username 23298 21997 0 76 0 - 25768 rt_sig Apr24 pts/6 00:00:00 /usr/bin/bcompare

[grunt]

Just curious, what OS are you using, grunt?
RHEL4u4-based thingie (kernel 2.6.9-42.7.ELsmp), KDE 3.3.1, BC3 3.0.0.453

[grunt]

OK, unfortunately I wasn't able to reproduce this. Have you noticed this in other session types?
don't think so. in text compare sessions bc3 occasionally starts flooding me with its exception windows, sometimes it just drops dead with no explanation, but i don't think i've seen the particular <ctrl>+<home> issue in either text compare or dir compare modes...

Are you using a build prior to 453? Which distribution are you using?
see my reply above to michael.

Perhaps a core dump could prove useful.
i'll try to scoop one up next time this happens.

[Craig]

as an aside, does that look right? at the moment i'm running AT MOST one instance

Looks like the idle timeout on background threads isn't kicking in properly. BC uses lots of background threads, but they usually terminate after a bit of time if they aren't being used. We've had trouble with that in the past because it can link against the wrong thread library (some distros still link BC against linuxthreads instead of NPTL), but I thought we'd worked around that.