public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* Re: gdb problem
@ 2000-06-02  6:25 Earnie Boyd
  2000-06-02  8:32 ` Chris Faylor
  2000-06-02 10:02 ` Jonathan Larmour
  0 siblings, 2 replies; 35+ messages in thread
From: Earnie Boyd @ 2000-06-02  6:25 UTC (permalink / raw)
  To: Tom M. Yeh, Cygwin

Purposed changes to the winsup/cygwin/path.cc source have caused a defect in
the tk portion of gdb.  You can see the source by using the non-windowed
version.

Regards,
Earnie.
--- "Tom M. Yeh" <tomyeh@infoshock.com> wrote:
> I installed the latest version of Cygwin (5/15/00). When I used gdb to debug
> a program, gdb popped up a dialog saying it cannot open the source file.
> What happens? The problem is still there even I compiled a program as simple
> as "hello world".
> 
> Regards,
> Tom
> 
> Here is the stack trace.
> ----------------------------------------------
> couldn't stat "/home/tomyeh/myprj/nolib/main.c": no such file or directory
>     while executing
> "file mtime $f"
>     (object "::.srcwin0.srcwin.container.pane1.childsite.con" method
> "::SrcTextWin::_mtime_changed" body line 7)
>     invoked from within
> "_mtime_changed $filename"
>     (object "::.srcwin0.srcwin.container.pane1.childsite.con" method
> "::SrcTextWin::FillSource" body line 10)
>     invoked from within
> "FillSource t $tagname $filename $funcname $line $addr $pc_addr $lib"
>     ("SOURCE" arm line 2)
>     invoked from within
> "switch $current(mode) {
>     SOURCE {
>       FillSource t $tagname $filename $funcname $line $addr $pc_addr $lib
>     }
>     ASSEMBLY {
>       FillAssembly..."
>     (object "::.srcwin0.srcwin.container.pane1.childsite.con" method
> "::SrcTextWin::location" body line 26)
>     invoked from within
> "$twin location $tag $name $funcname $line $addr $pc_addr $lib"
>     (object "::.srcwin0.srcwin" method "::SrcWin::location" body line 52)
>     invoked from within
> "location BROWSE_TAG [list $val "" $full 0 0 0 {}]"
>     (object "::.srcwin0.srcwin" method "::SrcWin::_name" body line 22)
>     invoked from within
> "::.srcwin0.srcwin _name .srcwin0.srcwin.container.pane3.childsite.con.name
> main.c"
>     (in namespace inscope "::SrcWin" script line 1)
>     invoked from within
> "namespace inscope ::SrcWin {::.srcwin0.srcwin _name}
> ..srcwin0.srcwin.container.pane3.childsite.con.name main.c"
>     ("after" script)errorCode is POSIX ENOENT {no such file or directory}
> 
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com
> 


__________________________________________________
Do You Yahoo!?
Yahoo! Photos -- now, 100 FREE prints!
http://photos.yahoo.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

^ permalink raw reply	[flat|nested] 35+ messages in thread
* gdb problem
@ 2011-10-22 20:38 Ken Brown
  2011-10-23  2:37 ` jan.kolar
  2011-10-23 19:04 ` Christopher Faylor
  0 siblings, 2 replies; 35+ messages in thread
From: Ken Brown @ 2011-10-22 20:38 UTC (permalink / raw)
  To: cygwin

[-- Attachment #1: Type: text/plain, Size: 942 bytes --]

The attached testcase illustrates a problem with `gdb -i=mi'.  I've 
tested both gdb 7.3.50-1 and 7.3.50-2, with cygwin 1.7.9 as well as with 
several recent snapshots (including 2011-10-22).

Under some circumstances, if gdb -i=mi is started and given several 
input lines at once, it only prints part of the output before stopping. 
  I've been able to reproduce this once in a while while working 
interactively (by copying and pasting the whole bunch of input lines); 
in this case one can press Return to get the rest of the output.  But 
the problem happens consistently with the attached test case, which runs 
gdb in a subprocess.  One has to kill the gdb process before the main 
program exits.

The STC runs as expected on Linux.

The particular input lines I gave gdb are precisely those that emacs 
sends in the problem I reported in

   http://cygwin.com/ml/cygwin/2011-10/msg00357.html .

I don't know if this is relevant.

Ken

[-- Attachment #2: stc.c --]
[-- Type: text/plain, Size: 1340 bytes --]

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <pty.h>
#include <string.h>
#include <sys/wait.h>

void get_output (int fd);

int
main () 
{
  int master;
  pid_t pid;

  if ((pid = forkpty (&master, NULL, NULL, NULL)) < 0)
    {
      perror ("forkpty");
      exit (1);
    }
  /* child */
  if (pid == 0) 
    {
      char  *argv[3];
      argv[0] = "gdb";
      argv[1] = "-i=mi";
      argv[2] = '\0';
      execvp (argv[0], argv);
      /* shouldn't get here */
      exit (1);
    }
  /* parent */
  char *input[10];

  input[0] = "1-inferior-tty-set /dev/pty3\n";
  input[1] = "2-gdb-set height 0\n";
  input[2] = "3-gdb-set non-stop 1\n";
  input[3] = "4-file-list-exec-source-files\n";
  input[4] = "5-file-list-exec-source-file\n";
  input[5] = "6-gdb-show prompt\n";
  input[6] = "7-stack-info-frame\n";
  input[7] = "8-thread-info\n";
  input[8] = "9-break-list\n";
  input[9] = "q\n";

  int i;
  for (i = 0; i < 10; ++i)
    write (master, input[i], strlen (input[i]));
  get_output (master);
  wait (NULL);
}

void
get_output (int fd)
{
#define BUFSIZE 1024
  char buf[BUFSIZE];
  int i;

  for (i = 0; i < 10; ++i)
    {
      int nread;
      nread = read (fd, buf, BUFSIZE);
      if (nread > 0)
	write (STDOUT_FILENO, buf, nread);
      else
	{
	  printf ("No more output.\n");
	  break;
	}
    }
}


[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

^ permalink raw reply	[flat|nested] 35+ messages in thread
* RE: gdb problem
@ 2004-01-27 14:50 RS
  2004-01-28  0:02 ` Christopher Faylor
  0 siblings, 1 reply; 35+ messages in thread
From: RS @ 2004-01-27 14:50 UTC (permalink / raw)
  To: cygwin; +Cc: rs

> Don't use CYGWIN=tty when debugging.  It confuses the debugee.
> cgf

First of all thank you, it really helps when I start a shell using
"cygwin\cygwin.bat".
But I do not understand why it helps, because gdb is a unix program and
I thought that
problems with tty option may occur with Windows programs.
Another point is that I commonly use
"cygwin\usr\X11R6\bin\startxwin.bat" to start a shell.
Here no CYGWIN environment variable is defined. Nevertheless I have the
problem with
gdb in this case.

Thank you in advance,
Robert



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

^ permalink raw reply	[flat|nested] 35+ messages in thread
* gdb problem
@ 2004-01-26 20:04 RS
  2004-01-26 20:38 ` Christopher Faylor
  0 siblings, 1 reply; 35+ messages in thread
From: RS @ 2004-01-26 20:04 UTC (permalink / raw)
  To: cygwin; +Cc: rs

Using gdb under cygwin I had a problem that can be demonstrated with
following
little program:

==================================
#include <stdio.h>

int main()
{
  char str[100];
  printf("Hello !\n");
  scanf("%s", str);
  printf("str: %s\n", str);
  scanf("%s", str);
  printf("str: %s\n", str);
  return -1;
}
==================================

With Linux (Debian Woody) gdb works fine:
==================================
$ gdb hello
GNU gdb 2002-04-01-cvs
Copyright 2002 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 "i386-linux"...
(gdb) r
Starting program: /home/rs/t/hello
Hello !
ttt
str: ttt
sss
str: sss

Program exited with code 0377.
==================================

Under Cygwin (Win98 and Win2k) text written to stdout is printed only
after finishing the
last input to stdin:
==================================
bash-2.05b$ gdb hello
GNU gdb 2003-09-20-cvs (cygwin-special)
Copyright 2003 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-cygwin"...
(gdb) r
Starting program: /home/rs/t/hello.exe
ttt
sss
Hello !
str: ttt
str: sss

Program exited with code 0177777.
==================================

Thank you for any hint,
Robert




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

^ permalink raw reply	[flat|nested] 35+ messages in thread
* RE: Gdb problem
@ 2001-08-28  0:59 Wolfgang Fritz
  0 siblings, 0 replies; 35+ messages in thread
From: Wolfgang Fritz @ 2001-08-28  0:59 UTC (permalink / raw)
  To: cygwin

Did you enable debugging during compile and link (gcc option -g)?

> -----Original Message-----
> From: Jorge Goncalvez [ mailto:goncal11@col.bsf.alcatel.fr ]
> Sent: Tuesday, August 28, 2001 9:42 AM
> To: cygwin@sources.redhat.com
> Subject: Re:Gdb problem
> 
> 
> Hi, I am tring to debug a port of the iSC DHCPD under cygwin 
> but when I use Gdb 
> I only can select Assembly language instead of source code.
> Why?
> 
> 
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
> 
>

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

^ permalink raw reply	[flat|nested] 35+ messages in thread
* Re:Gdb problem
@ 2001-08-28  0:45 Jorge Goncalvez
  2001-08-28  0:55 ` Gdb problem Andrew Markebo
  0 siblings, 1 reply; 35+ messages in thread
From: Jorge Goncalvez @ 2001-08-28  0:45 UTC (permalink / raw)
  To: cygwin

Hi, I am tring to debug a port of the iSC DHCPD under cygwin but when I use Gdb 
I only can select Assembly language instead of source code.
Why?


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

^ permalink raw reply	[flat|nested] 35+ messages in thread
[parent not found: <NFBBJHGBKLKEAOHMECHMEEDECAAA.yrwang@cc.nctu.edu.tw>]
* gdb problem
@ 2000-06-02  5:50 Tom M. Yeh
  0 siblings, 0 replies; 35+ messages in thread
From: Tom M. Yeh @ 2000-06-02  5:50 UTC (permalink / raw)
  To: Cygwin

I installed the latest version of Cygwin (5/15/00). When I used gdb to debug
a program, gdb popped up a dialog saying it cannot open the source file.
What happens? The problem is still there even I compiled a program as simple
as "hello world".

Regards,
Tom

Here is the stack trace.
----------------------------------------------
couldn't stat "/home/tomyeh/myprj/nolib/main.c": no such file or directory
    while executing
"file mtime $f"
    (object "::.srcwin0.srcwin.container.pane1.childsite.con" method
"::SrcTextWin::_mtime_changed" body line 7)
    invoked from within
"_mtime_changed $filename"
    (object "::.srcwin0.srcwin.container.pane1.childsite.con" method
"::SrcTextWin::FillSource" body line 10)
    invoked from within
"FillSource t $tagname $filename $funcname $line $addr $pc_addr $lib"
    ("SOURCE" arm line 2)
    invoked from within
"switch $current(mode) {
    SOURCE {
      FillSource t $tagname $filename $funcname $line $addr $pc_addr $lib
    }
    ASSEMBLY {
      FillAssembly..."
    (object "::.srcwin0.srcwin.container.pane1.childsite.con" method
"::SrcTextWin::location" body line 26)
    invoked from within
"$twin location $tag $name $funcname $line $addr $pc_addr $lib"
    (object "::.srcwin0.srcwin" method "::SrcWin::location" body line 52)
    invoked from within
"location BROWSE_TAG [list $val "" $full 0 0 0 {}]"
    (object "::.srcwin0.srcwin" method "::SrcWin::_name" body line 22)
    invoked from within
"::.srcwin0.srcwin _name .srcwin0.srcwin.container.pane3.childsite.con.name
main.c"
    (in namespace inscope "::SrcWin" script line 1)
    invoked from within
"namespace inscope ::SrcWin {::.srcwin0.srcwin _name}
.srcwin0.srcwin.container.pane3.childsite.con.name main.c"
    ("after" script)errorCode is POSIX ENOENT {no such file or directory}


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

^ permalink raw reply	[flat|nested] 35+ messages in thread
* gdb problem
@ 1999-03-29 12:22 Igor Sheyn
  1999-03-29 16:45 ` Chris Faylor
  1999-03-31 19:45 ` Igor Sheyn
  0 siblings, 2 replies; 35+ messages in thread
From: Igor Sheyn @ 1999-03-29 12:22 UTC (permalink / raw)
  To: cygwin

Hi,

I'm running B20.1 on NT4.0.
I started gdb and tried to run a program.  Here's what I see:
------------------------------------------------------------------------
Starting program: /src/pari-2.0.15.alpha/o.cygwin_nt-4.0-i586.dbg/gp-sta.exe -q
61000000:/cygnus/CYGWIN~1/H-I586~1/bin/cygwin1.dll

[failed reading symbols from DLL]
"/WINNT/system32/advapi32.dll": error reading line numbers


[failed reading symbols from DLL]
"/WINNT/system32/KERNEL32.dll": error reading line numbers

77e70000:/WINNT/system32/USER32.dll
77ed0000:/WINNT/system32/GDI32.dll
77e10000:/WINNT/system32/RPCRT4.dll
77bf0000:/WINNT/System32/rpcltc1.dll
------------------------------------------------------------------------
Any ideas why the error?  I have full administrative rights on my PC
and am logged in locally, not into domain.

Thanks

Igor

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

^ permalink raw reply	[flat|nested] 35+ messages in thread
* GDB Problem
@ 1997-10-29 17:22 Sudhakar Ganti
  1997-10-30  5:48 ` Chris Faylor
  0 siblings, 1 reply; 35+ messages in thread
From: Sudhakar Ganti @ 1997-10-29 17:22 UTC (permalink / raw)
  To: gnu-win32

Hi,

I recently intalled the GNU-Win32 package the beta 18 version. I installed
everything as outlined (from the binaries). I have a problem with the
gdb, both command line (-nw option) or the windows version.

Specifically when I load a file and run it, the gdb says that
it has failed reading the symbols from DLLs: shlwapi.dll and comctl32.dll.
Then the programs runs OK. But when I quit gdb, the DOS window is not closed
and the Windows95 reports an error message "GDB casued an invalid
page fault in cw3215.dll". At this point I cannot even close the DOS
window, as well I cannot shut down Windows95. This is all from commandline
with -nw option. If I run the gdb with the windows (no -nw option) it shows 
the windows, but when I try to load any file and run, it hangs.

I looked in the mail archives and did not find any queries
regarding this. Any help will be appreciated.

-Sudhakar
    __o      __o                       
--_`\<-_---_`\<-_-------Sudhakar Ganti------------
 (_)/ (_) (_)/ (_)    Nepean, Ontario, Canada   
--------------------------------------------------

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

^ permalink raw reply	[flat|nested] 35+ messages in thread
* GDB Problem
@ 1997-09-24  6:57 Bardley09
  0 siblings, 0 replies; 35+ messages in thread
From: Bardley09 @ 1997-09-24  6:57 UTC (permalink / raw)
  To: gnu-win32

GDB can't find main.tcl (and crashes on exit, apparently harmlessly) despite
the fact that it's there and the env variable is set up correctly with
forward slashes:

GDBTK_LIBRARY= C:/gnuwin32/b18/share/gdbtcl

I noticed in the faq (or was it the readme file) it says it should be 'tcl'
instead of 'gdbtcl'.  I assumed this wasn't right.  I'm using W95.  Any help
on this will be much appreciated.  Oh, and the rest of my environment is
correctly set up as far as i know....

Thank you.


-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

^ permalink raw reply	[flat|nested] 35+ messages in thread
* Re: GDB problem
@ 1997-07-09  5:31 Bryan Rosenburg
  0 siblings, 0 replies; 35+ messages in thread
From: Bryan Rosenburg @ 1997-07-09  5:31 UTC (permalink / raw)
  To: gnu-win32; +Cc: noer, shebs

I wrote:
> On four of our Windows-95 machines, a simple "gdb -nw" followed
> by "quit" results in an "illegal operation" error but has no other ill
> effects.  But on the fifth machine, the same sequence consistently
results
> in gdb hanging in an unkillable state and consuming 90% or more of the
CPU.

The gdb hanging problem turned out to be of our own making.  On the problem
machine we had a "default application debugger" (not gdb) installed, but
the
debugger was misconfigured.  When gdb generated its illegal operation on
exit
(which it always does), the system went into a loop trying to invoke the
debugger executable which wasn't where it was supposed to be.  With no
default debugger installed, gdb's illegal operation on exit is benign.

With this problem solved, gdb in b18 has been quite stable and useful.

Bryan Rosenburg
rosnbrg@watson.ibm.com


-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

^ permalink raw reply	[flat|nested] 35+ messages in thread
* Re: GDB problem
@ 1997-07-08  6:58 Bryan Rosenburg
  0 siblings, 0 replies; 35+ messages in thread
From: Bryan Rosenburg @ 1997-07-08  6:58 UTC (permalink / raw)
  To: noer; +Cc: hamann, gnu-win32

Geoffrey Noer writes:
> My main problem with the gdb in beta 18 is the crash on exit
> problem.  I hope it will be fixed in future releases...
and:
> My consistent problem is quitting the tcl/tk gdb (I believe the problem
> is actually in tcl/tk rather than in gdb).  That said, I find the b18 gdb
> to be fairly usable so you may not need to completely abandon using it
> because of this problem.

In my group, gdb is "fairly usable" on some machines but not on others, and
the problem seems to be independent of whether or not we use the tcl/tk
front end.  On four of our Windows-95 machines, a simple "gdb -nw" followed
by "quit" results in an "illegal operation" error but has no other ill
effects.  But on the fifth machine, the same sequence consistently results
in gdb hanging in an unkillable state and consuming 90% or more of the CPU.
Killing it manually using ctrl-alt-del gets it out of the Close Program
dialog, but the CPU is still saturated and wintop (from Microsoft's
Kernel Toys) shows GDB.EXE to still be consuming all the cycles it can get.
We've found no way to recover short of rebooting.

We're running b18 with Sergey's May26 patch.  (The patch has no effect on
this problem).  On two Windows-NT boxes with the same setup, gdb runs
without error.

This problem has become a serious obstacle for us.  Any suggestions, fixes,
or workarounds would be most welcome.

Bryan Rosenburg
rosnbrg@watson.ibm.com


-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

^ permalink raw reply	[flat|nested] 35+ messages in thread
* GDB problem
@ 1997-07-06  4:46 Mark Hamann
  1997-07-06 15:34 ` J.R. Dean
  0 siblings, 1 reply; 35+ messages in thread
From: Mark Hamann @ 1997-07-06  4:46 UTC (permalink / raw)
  To: gnu-win32

I have just installed the Win32 tools in Windows 95 and I am having some
problems.  The GDB environment is very unstable.  It causes my system to
crash or causes bash to hang up when the debugged program finishes or I use
the 'kill' command or I use the 'close' from the menu bar.  I can use
'quit' from the menu bar, but I still have to hit ctrl-alt-del and
terminate the task manually.  I would invoke the command line version if I
had an xterm or the DOS prompt had scrollbars.  Is there something I can
do?

I looked through the archives for this question, but I didn't see it.  All
of the questions looked like a higher level than this and everyone seems to
be using NT, so accept my apologies. Maybe someday I will know what I am
doing and my company will take OS's seriously and switch from 95 to NT;->.

Thanks,
Mark Hamann

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

^ permalink raw reply	[flat|nested] 35+ messages in thread

end of thread, other threads:[~2012-05-05  1:58 UTC | newest]

Thread overview: 35+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-06-02  6:25 gdb problem Earnie Boyd
2000-06-02  8:32 ` Chris Faylor
2000-06-02 10:02 ` Jonathan Larmour
2000-06-02 10:03   ` Jonathan Larmour
  -- strict thread matches above, loose matches on Subject: below --
2011-10-22 20:38 Ken Brown
2011-10-23  2:37 ` jan.kolar
2011-10-23 19:04 ` Christopher Faylor
2011-10-23 21:48   ` Ken Brown
2012-05-03 20:05     ` Ken Brown
2012-05-04  3:10       ` Christopher Faylor
2012-05-04 19:20         ` Ken Brown
2012-05-05  1:58           ` Ryan Johnson
2004-01-27 14:50 RS
2004-01-28  0:02 ` Christopher Faylor
2004-01-26 20:04 RS
2004-01-26 20:38 ` Christopher Faylor
2001-08-28  0:59 Gdb problem Wolfgang Fritz
2001-08-28  0:45 problem Jorge Goncalvez
2001-08-28  0:55 ` Gdb problem Andrew Markebo
     [not found] <NFBBJHGBKLKEAOHMECHMEEDECAAA.yrwang@cc.nctu.edu.tw>
2001-05-22  3:12 ` gdb problem egor duda
2000-06-02  5:50 Tom M. Yeh
1999-03-29 12:22 Igor Sheyn
1999-03-29 16:45 ` Chris Faylor
1999-03-31 19:45   ` Chris Faylor
1999-03-31 19:45 ` Igor Sheyn
1997-10-29 17:22 GDB Problem Sudhakar Ganti
1997-10-30  5:48 ` Chris Faylor
1997-09-24  6:57 Bardley09
1997-07-09  5:31 GDB problem Bryan Rosenburg
1997-07-08  6:58 Bryan Rosenburg
1997-07-06  4:46 Mark Hamann
1997-07-06 15:34 ` J.R. Dean
1997-07-07 15:27   ` Geoffrey Noer
1997-07-07 23:30     ` J.R. Dean
1997-07-08  0:56       ` Geoffrey Noer
1997-07-08  6:58         ` Stuart Williams

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).