Crash using copy and paste (reproducable)

[Pecan]

This is bugging me too. I'm using C::B Revison 3593, OpenSUSE 10.2, wxGTK-2.6.3.1 and wx is compiled as Release-Dynamic-Unicode-Monolithic.

@Biplab
C::B crashes after using Ctrl+V or Edit>Paste.

Since you're getting this crash, could you trap it and give us a backtrace.
You can use the follow (or like) bash shell to trap the crash.

Code

#!/bin/sh
echo run>run.txt
APP_DIR=`pwd`
export LD_LIBRARY_PATH=$APP_DIR:$LD_LIBRARY_PATH
gdb --command=run.txt --args $APP_DIR/codeblocks $@

If you're using windows, just run codeblocks under gdb, like

gdb codeblocks
run

You can make a .cmd file for it like:

Code

echo run>run.txt
gdb -command=run.txt codeblocks

[Biplab]

This is bugging me too. I'm using C::B Revison 3593, OpenSUSE 10.2, wxGTK-2.6.3.1 and wx is compiled as Release-Dynamic-Unicode-Monolithic.

@Biplab
C::B crashes after using Ctrl+V or Edit>Paste.

Since you're getting this crash, could you trap it and give us a backtrace.
You can use the follow (or like) bash shell to trap the crash.

Code

#!/bin/sh
echo run>run.txt
APP_DIR=`pwd`
export LD_LIBRARY_PATH=$APP_DIR:$LD_LIBRARY_PATH
gdb --command=run.txt --args $APP_DIR/codeblocks $@

Thanks a lot for the detailed instruction. I'm not familiar with GDB and they will help me a lot.

I'll post it after some time. (Currently I'm in Windows and compiling GCC-3.4.6. It's not over yet.

By the way do I need to run it from src/devel dir or I can run it from /usr/local/bin dir ?

[fleuba]

Hi again,

Sorry you guys if my post looked a bit upseting. I'm just so fed up with this bug, but in the meanwhile I know developping such a big and great software is a lot of work.
This bug seems to occure only for a few people, so it is tempting to move it very far in the todo list.
Nevertheless, thank you for the answer. I'll reproduce the bug and provide you with the crash stack today.
I hope this will help you to fix it... I can cooperate even more as you need.

Fred

[Pecan]

@Biplab:

When in wndows, run it from the src/devel.

When in Linux run it from where the codeblocks executable is.

Else just change the APP_DIR=`pwd` to the dir of codeblocks, and run it from anywhere.

For example, here's one without gdb running the nightly install (not my compiled svn install) from /home/pecan/cbNightly/usr/bin with the LIB also changed.
I cd to /home/pecan/cbNightly/usr/bin and issue ./run.sh

Code

#!/bin/sh
APP_DIR=`pwd`
export LD_LIBRARY_PATH=$APP_DIR/lib:$LD_LIBRARY_PATH
$APP_DIR/bin/codeblocks --prefix=$APP_DIR $@

When the crash finally occurs, issue the command:
bt full

and keep hitting enter (not quit) until the backtrace finishes with a (gdb) prompt.

copy and paste to taste. I like to open an external editor and paste the whole monte so I can restart CB and read the trace later.

[Pecan]

Here's a nice 2 page quick reference for GDB.
http://www.cs.dal.ca/studentservices/refcards/gdbref.pdf

KeyWords: GDB Quick Reference

[Biplab]

@Pecan

My sincere thanks for the help. I'll try my best to learn GDB. 

I tried for about 10 minutes, but didn't find any crash. It's strange I'm using the same application. I ran the application with the following script (from ur example).

Code

#!/bin/sh
APP_DIR=/usr/local
export LD_LIBRARY_PATH=$APP_DIR/lib:$LD_LIBRARY_PATH
$APP_DIR/bin/codeblocks --prefix=$APP_DIR $@

I usually run the App using the following Desktop Shortcut (I'm not sure about it's Linux name)

Code

[Desktop Entry]
Version=1.0
Encoding=UTF-8
Name=Code::Blocks
Comment=
Comment[en_US]=
Exec='/usr/local/bin/codeblocks'
GenericName=Code::Blocks IDE
GenericName[en_US]=Code::Blocks IDE
Icon=
MimeType=;
Name[en_US]=Code::Blocks
Path=
StartupNotify=true
Terminal=false
TerminalOptions=
Type=Application
X-DCOP-ServiceType=
X-KDE-SubstituteUID=false
X-KDE-Username=

I've to leave my lab right now (It's 12am and the AC is switched off ) But please point out any problem you find.

I'll keep trying to reproduce crash report, if any.

Thanks & Regards,

Biplab

[Pecan]

I tried for about 10 minutes, but didn't find any crash. It's strange I'm using the same application. I ran the application with the following script (from ur example).

Code

#!/bin/sh
APP_DIR=/usr/local
export LD_LIBRARY_PATH=$APP_DIR/lib:$LD_LIBRARY_PATH
$APP_DIR/bin/codeblocks --prefix=$APP_DIR $@

To catch the crash you have to run from a terminal or xterm, and shouldn't that last line be:
gdb --args $APP_DIR/bin/codeblocks --prefix=$APP_DIR $@

I made the assumption that you're running the svn version of CB.


On Linux: in the /src/devel directory you'll find the distributed ./run.sh shell command. I modify that shell command to startup gdb with codeblocks as the debugee. That shell I posted is just a modification of the run.sh.

So when I test CodeBlocks, I do the following:
I start a terminal or xterm. I then
cd /home/pecan/devel/trunk/src/devel
./run.sh

On windows:
I start a dos session. Then issue the dos commands:
cd \usr\proj\trunk\src\devel
gdb codeblocks
I get the (gdb) prompt then type
run

Then I just do my thing until CB crashes, where upon I get the (gdb) prompt again with a message about a segxxx, where xxx is  some sort of violation.
I issue:
bt full to get the backtrace.

I usually run the App using the following Desktop Shortcut (I'm not sure about it's Linux name)

Code

[Desktop Entry]
Version=1.0
Encoding=UTF-8
Name=Code::Blocks
Comment=
Comment[en_US]=
Exec='/usr/local/bin/codeblocks'
GenericName=Code::Blocks IDE
GenericName[en_US]=Code::Blocks IDE
Icon=
MimeType=;
Name[en_US]=Code::Blocks
Path=
StartupNotify=true
Terminal=false
TerminalOptions=
Type=Application
X-DCOP-ServiceType=
X-KDE-SubstituteUID=false
X-KDE-Username=

Sorry, I don't know what the above is. Some KDE thingie ?

[Biplab]

To catch the crash you have to run from a terminal or xterm, and shouldn't that last line be:
gdb --args $APP_DIR/bin/codeblocks --prefix=$APP_DIR $@

I made the assumption that you're running the svn version of CB.


On Linux: in the /src/devel directory you'll find the distributed ./run.sh shell command.

So when I test CodeBlocks, I do the following:
I start a terminal or xterm. I then
cd /home/pecan/devel/trunk/src/devel
./run.sh

That shell I posted is just a modification ofthe run.sh.

On windows:
I start a dos session. Then issue the dos commands:
cd \usr\proj\trunk\src\devel
gdb codeblocks

Ok, I was in a hurry so couldn't post much details.

What I did was to save that content in a run.sh file and then ran it by right-clicking on it. I know this is utterly wrong, but some Windows habits it is.

I was getting strange error that Permission denied when I was running from shell. So I changed the property of file to Executable (again Right-click) and then selected run menu option.

But I didn't notice any crash. Earlier during crash once I press Ctrl+V everything was gone.

Another point to note that after posting the crash report I downloaded the wx-2.6.3-p2 and reinstalled it.

I'm using SVN version and will try tomorrow again as you've demonstrated. Whenever I try to use ./run.sh in src/devel folder, I get "Permission denied" message. Even in SU mode, it throws same error. May be I need to do the Right-click again to make it executable.

Honestly speaking I'm a Newbie in Linux and I face these strange (but simple) problems.

Sorry, I don't know what the above is. Some KDE thingie ?

That is equivalent of Shortcut in Windows. This is to help Newbies like us to launch an app without using shell script. 

I posted it's content to show you how I launch C::B.

Thanks again for your introduction to GDB. 

Regards,

Biplab

[Pecan]

I need to do the Right-click again to make it executable.

Oh, yes, you're right. It needs to be made executable

In a terminal or xterm issue the command:

cd to your .../src/devel
chmod +x run.sh (or whatever you named it.)
./run.sh 

I copied my original run.sh to gdb.sh
modified it to execute gdb as we've discussed.
chmod +x gdb.sh

Then just cd to your ...src//devel
./gdb.sh

[Biplab]

Thanks for the instruction. 

But I would like to ask another question regarding debugging of wxWidgets based app with GDB in Linux. I read the following post in wxWidgets forum.

http://wxforum.shadonet.com/viewtopic.php?t=12530

It says that the user can't see the contents of wxString with GDB in Unicode mode. I tried it and found that in C::B too, in Watches Window I can't see the wxString contents. AFAIK it's possible to view the contents of wxString in Unicode mode with MS Debugger. Why is it so?

[Pecan]

Thanks for the instruction. 

But I would like to ask another question regarding debugging of wxWidgets based app with GDB in Linux. I read the following post in wxWidgets forum.

http://wxforum.shadonet.com/viewtopic.php?t=12530

It says that the user can't see the contents of wxString with GDB in Unicode mode. I tried it and found that in C::B too, in Watches Window I can't see the wxString contents. AFAIK it's possible to view the contents of wxString in Unicode mode with MS Debugger. Why is it so?

I suppose because unicode is so full of zeros. It makes it look like the string is empty.

You would need a script to call cbU2C(my watched string) to make it into a c_str.

Just a guess.

I'm no script wizard, not even a novice, but you might be able to issue these commands to gdb and show the results:

Code

bool testwxApp::OnInit()
{
	testwxFrame* frame = new testwxFrame(0L, _("wxWidgets Application Template"));
	frame->SetIcon(wxICON(aaaa)); // To Set App Icon
	frame->Show();

	wxString msg;
	msg = wxT("test unicode string");
	asm("int3");
	return true;
}

C:\temp\testwx\bin>gdb testwx.exe
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-mingw32"...
(gdb) run
Starting program: C:\temp\testwx\bin/testwx.exe
gdb: do_initial_child_stuff: process 1572
gdb: kernel event for pid=1572 tid=288 code=CREATE_PROCESS_DEBUG_EVENT)
gdb: child_resume.SetThreadContext: thread 1572.0x120
ContinueDebugEvent (cpid=1572, ctid=288, DBG_CONTINUE);
<snip>
Program received signal SIGTRAP, Trace/breakpoint trap.
testwxApp::OnInit (this=0xb59290) at C:/temp/testwx/testwxApp.cpp:32
32              return true;
Current language:  auto; currently c++
(gdb) l
27              frame->Show();
28
29              wxString msg;
30              msg = wxT("test unicode string");
31              asm("int3");
32              return true;
33      }
(gdb) p msg
$1 = {<wxStringBase> = {static npos = 4294967295,
    m_pchData = 0xb6a654}, <No data fields>}
(gdb) p msg.m_pchData
$2 = (wxChar *) 0xb6a654
(gdb) x/20s msg.m_pchData
0xb6a654:        "t"
0xb6a656:        "e"
0xb6a658:        "s"
0xb6a65a:        "t"
0xb6a65c:        " "
0xb6a65e:        "u"
0xb6a660:        "n"
0xb6a662:        "i"
0xb6a664:        "c"
0xb6a666:        "o"
0xb6a668:        "d"
0xb6a66a:        "e"
0xb6a66c:        " "
0xb6a66e:        "s"
0xb6a670:        "t"
0xb6a672:        "r"
0xb6a674:        "i"
0xb6a676:        "n"
0xb6a678:        "g"
0xb6a67a:        ""
(gdb)

[Biplab]

Thanks for the details. 

Today I ran C::B through GDB. I got no crash during Copy-Paste operation. But I got some warning and critical error messages and one SIGSEGV fault. I'm attaching the full log alongwith BackTrace.

I'll post a link to your reply in wxWidgets forum, may be that would be helpful for the user.

I'm no script wizard, not even a novice, but you might be able to issue these commands to gdb and show the results:

BTW, I'm no script wiz, too.   Coz I was working on modifying the project wizards of C::B, I got that name. 

Please post if you need more GDB logs.

Regards,

Biplab


Edit 1: I observed the SIGSEGV fault during exit.

[attachment deleted by admin]

[fleuba]

Hi all,

C::B just crashed during copying a piece of code.
Attached is the backtrace, with some info on top of the file.

I'm available to help fixing this bug...
Give me instructions here to search, what to test for you.

CU,
Fred

[attachment deleted by admin]