Bluefish crashes when opening specific file

Sorry..forgot:

jacob@jacob-desktop:~$ lsb_release -rd
Description: Ubuntu 8.04
Release: 8.04

jacob@jacob-desktop:~$ apt-cache policy bluefish
bluefish:
  Installed: 1.0.7-4
  Candidate: 1.0.7-4
  Version table:
 *** 1.0.7-4 0
        500 http://us.archive.ubuntu.com hardy/universe Packages
        100 /var/lib/dpkg/status
jacob@jacob-desktop:~$

I don't have any problem to open this file, perhaps its something specific to your settings or system. Can you make a backtrace? This could help us to pinpoint the issue:

https://wiki.ubuntu.com/Backtrace

Cesare, which architecture? Can you send me your .bluefish/ directory? Because I can easily reproduce the problem. Seems like an endless loop in libpcre and then leading to a segementation fault.

Its amd64 for me, .bluefish attached.

jacob@jacob-desktop:~$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 10
model name : AMD Athlon(tm) XP 3200+
stepping : 0
cpu MHz : 2199.386
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow up ts
bogomips : 4401.10
clflush size : 32

I'm trying to add a useful backtrace but am unable to find the debugging symbols.

So Jacob, this is an i386 architecture too (no amd64), right?

I already have the backtrace. However:
https://wiki.ubuntu.com/DebuggingProgramCrash

Sure is. Not a 64 bit processor.

Backtrace.

Last 10 calls in the backtrace.

I thought this could be a stack overflow since the recursion depth is quite large (around 6800).
On my machine stack size (ulimit -s) is 8M, assuming 500 bytes per recursion (see pcrestack(3)) I'm safely within the limits.
Could this be different on 32 bits machines!?
I also checked the source with Konqueror, rkward and Kate, which, to my knowledge, also use pcre_exec for pattern matching in their syntax highlighting engines and everything is fine.

Could you check just the service_eyex_fadeOutLayer function (which is where the SIGSEGV occurs)?

If it is confirmed to be a stack limitation (can you check with gdb Daniel?), there are some hints about limiting the recursion depth in pcrestack(3) which my be worth looking into.

jacob@jacob-desktop:~$ ulimit -s
8192
jacob@jacob-desktop:~$

Found it. We cause it via String highlighting patterns. In Preferences > Highlighting choose the php-section and there change for String single/double quoted to begin- and end-pattern and put " or ' as beging and end pattern. Then Apply. Now everything should be fine.

That works for me! Thanks for looking into this.

Interesting enough, I had these options on (I guess they are the default ones since I never touched them), but, even if I do change them to no " and ' I still don't get a crash.

You never touched them? Well, I normally note, when pattern (and which) should be updated.

What means "even if I do change them to no ..."? Change them to start-pattern-only with the following pattern.

"(\\"|.)*?"

and try to reproduce the issue.

OK, but then even a simple '*? its enough to make it crash.
I'm still not getting what is your conclusion on this, is this a bug in bluefish or not?

I hope, you used .*? because *? is not a regex. The first was used some years ago in bf and then changed to, what caused the segfault.

I consider it a "bad pattern" in bluefish (and an update is waiting to be uploaded), for which we are responsible.

Now I'm even more confused. Using the following regexes for the start pattern only of double quoted and single quoted strings:

"(\\"|.)*?"
'(\\"|.)*?'

I'm not getting any crash when opening the above sample file. For what I can see all strings are highlighted correctly in green.

Its a typo in the previous comment, for single quoted string I used '(\\'|.)*?' not '(\\"|.)*?'

This bug was fixed in the package bluefish - 1.0.7-5

---------------
bluefish (1.0.7-5) unstable; urgency=low

  * debian/rules (build, clean): Moved the config.* copy action to
    config.status. Files can further be removed by dh_clean.
    (config.status): According to the manuals, variables should be given after
    the configure call.
  * debian/patches/03_latest_highlighting_pattern.dpatch: Adjusted.
    - Fix php highlighting pattern, that seem to lead to a segmentation fault on
      e.g. i386 architectures in some cases (LP: #228068).

 -- Ubuntu Archive Auto-Sync <email address hidden> Mon, 19 May 2008 07:39:36 +0100